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I ,  OVERVIEW  OF  MOPADS 


1-0  INTRODUCTION  TO  THE  MOPADS  PROJECT 

The  MOPADS  (Models  of  Operator  Peformance  in  Air  Defense 
Systems)  Project  has  developed  modeling  tools  to  represent  the 
performance  of  human  heings  in  complex  man-machine  air-defense 
systems.  The  primary  goals  of  MOPADS  were  to  create  an  analysis 
vehicle  that  is: 

1.  flexible  -  in  other  words,  able  to  model  a 

wide  variety  of  system  configu¬ 
rations,  human  factors  conditions, 
and  air  defense  scenarios, 

2.  expandable  -  i.e.,  amenable  to  inclusion  of 

additional  elements  of  air 
defense  systems  and  additional 
human  factors  considerations  with¬ 
out  disrupting  previously  exist¬ 
ing  features  and  with  a  reason¬ 
able  effort,  and 

3.  user-oriented  -  in  other  words,  sufficiently  easy 

to  use  so  that  a  professional 
behavioral  scientist  can  conduct 
meaningful  experiments  without 
performing  programming  or  explicit 
computer  modeling  activities. 

Success  in  achieving  these  goals  results  in  a  modeling 
tool  that  permits  low  cost  analysis  of  human  factors  considerations 
in  complex  air  defense  situations.  The  analyses  will  be  low  cost 
to  the  behavioral  scientist  because  the  main  expenditure  of  his/her 
time  will  be  in  creating  the  experimental  design  and  in  selecting 
the  various  input  parameters  for  MOPADS.  Expensive  single  purpose 
models  will  not  need  to  be  developed  for  each  new  application.  Also, 
if  the  MOPADS  system  is  expanded  to  provide  new  capabilities,  the 
analyst  will  not  have  to  learn  a  new  modeling  framework  or  new  data 
requirements,  formats,  etc.  Performing  the  experiments  will  be  low 
cost  also,  since  only  a  few  minutes  of  computer  time  will  be  required 
for  most  MOPADS  simulations. 
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2-0  FJMAH  FACTORS  MODELING  DJ  MOPADS  •  v  ' 

Since  operators  are  the  main  focus  of  MOPADS,  the  way  in  which 
human  factors  are  represented  in  the  models  is  central  to  +he 
methodology.  Human  factors  affect  the  simulation  outcomes  in 
two  ways: 

1.  by  affecting  activity  performance  times,  and 

2.  by  affecting  operator  task  sequencing. 

Three  types  of  operator  activities  are  represented  in  MOPADS. 
The  first  is  skill  based  behavior.  This  type  of  behavior  involves 
actions  requiring  one  or  more  skills  such  as  tracking,  detection, 
and  fine  manipulation.  Skill  based  behaviors  are  simple  control 
actions.  Examples  in  the  Air  Defense  setting  are  pressing  appro¬ 
priate  buttons,  entering  alphanumeric  values  on  a  keyboard,  and 
locating  a  symbol  on  a  display.  Zn  MOPADS  terminology,  these 
actions  are  called  "task  elements"becaune  they  are  the  components  of 
operator  tasks.  MOPADS  task  elements  correspond  to  the  lowest  level 
of  instruction  information  found  in  Army  documentation.  For  example, 
when  an  AN/TSQ-73  operator  performs  a  number  hook,  one  of  the  actions 
required  is  to  enter  a  track  identifier  on  a  keyboard.  This  activity 
obviously  requires  hand  and  arm  motions,  finger  motions,  eye  motions, 
and  head  motion.  MOPADS  does  not  explicitly  represent  these  com¬ 
ponents  of  the  activity,  father,  the  skills  required  for  this 
action  are  specified,  and  the  human  factors  modules  compute  the 
time  required.  The  MOPADS  model  contains  only  a  single  modeling 
symbol  that  represents  the  keyboard  entry.  This  means  that  there  is 
a  nearly  one-to-one  match  between  MOPADS  model  symbols  and  Amy 
system  documentation.  Also,  data  collection  is  restricted  to  values 
which  can  be  directly  observed  from  operator  actions. 

The  second  type  of  behavior  represented  in  MOPADS  is  rule 
based  behavior.  This  type  of  behavior  is  typified  by  the  perfor¬ 
mance  of  check  lists.  Much  of  the  activity  of  air  defense  operators 
can  be  classified  as  rule  based  behavior.  Operator  tasks  (sometimes 
called  "critical  tasks")  rre  specified  in  Amy  documentation,  and 
they  are,  in  effect,  check  lists  which  the  operators  memorize. 
Operator  tasks  (or  simply  "tasks")  involve  skill  based  actions  (task 
elements),  and  simple  decisions.  Examples  include  hooking  a  track, 
clearing  alerts,  and  manually  identifying  a  track. 

Operator  tasks  are  al3o  obtained  directly  from  Army  documen¬ 
tation,  and  there  is  a  nearly  one-to-one  correspondence  between 
official  documents  and  MOPADS  representations  of  tasks.  In  the  same 
way  that  a  single  MOPADS  modeling  symbol  represents  a  single 
task  element,  a  collection  of  such  MOPADS  symbols  represents  an 
operator  task. 


1-2 


The  third  type  behavior  represented  .in  MOPADS  is  knowledge 
based  behavior.  This  type  e *  behavior  is  strategic  in  nature .  Air 
defense  operators  perform  this  type  of  behavior  in  selecting  which 
tasks  tc  perform  in  order  to  accomplish  tneir  mission,  in  particu¬ 
lar,  the  o^/erators  must  decide  vhich  operator  tasks  to  perform  and' 
in  what  older.  The  MOPADS  itrm  for  this  activity  is  "task 
sequencing."  MOPADS  operators  ore  represented  as  goal  seekers. 

They  evaluate  the  potential  impact  of  available  operator  tasks  on 
their  goals  when  selecting  the  next  task  to  perform. 

It  is  more  difficult  to  obtain  Army  documentation  references 
for  operator  goals  because  they  result  from  common  practice, 
standard  operating  procedures  and  individual  operator  motivations. 
The  approach  taken  in  MOPADS  has  been  to  consult  subject  matter 
experts  (in  addition  to  Army  documentation)  to  determine  a  suffi¬ 
cient  set  of  operator  goals. 

It  is  clear  that  the  way  human  factors  modeling  is  performed 
in  MOPADS  will  be  the  central  concern  of  behavioral  scientists  and 
that  no  such  methodology  is  sufficiently  well  established  so  as  to 
elicit  no  controversy.  Therefore,  the  human  factors  modules 
developed  for  MOPADS  are  stand-alone  -oft ware  modules.  This  means 
that  other  researchers  will  be  able  t  •  experiment  with  the  metho¬ 
dology  in  a  context  removed  from  the  .JOPADS  project.  Furthermore, 
the  modules  are  sufficiently  well  documented  bo  that  other 
researchers  can  test  alternate  parameter  values  and  even  substitute 
human  performance  equations. 

This  approach  has  benefits  to  MOPADS  in  that  alternate  human 
feet ora  representations  ern  be  readily  tested  within  the  MOPADS 
system,  and  it  will  hopefully  provide  a  useful  tool  for  behavioral 
scientists  to  evaluate  theories  in  &  unified  framework. 

3-0  SIMULATION  METHODOLOGY  IN  MOPADS 

The  simulation  methodology  selected  for  MOPADS  is  discrete 
event  simulation.  This  means  that  the  computer  explicitly  repre¬ 
sents  each  action  and  event  (  to  the  level  of  detail  selected  by 
the  modeler)  that  occurs  in  the  system.  This  is  in  contrast  to 
algebraic  or  differential  equation  models  which  aggregate  and 
smooth  individual  events  to  obtain  overall  average  performance 
measures. 

The  advantages,  in  the  MOPADS  context,  of  a  discrete  event 
simulation  are: 

1.  An  actual  time  history  of  events  is  produced  by  the 
simulation.  This  can  be  important  for  interfacing 
the  simulation  with  real  time  hardware  simulators  or 
field  equipment,  since  the  simulator  events  will  more 
closely  approximate  the  events  in  the  "live"  systems. 
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Discrete  event  modeling  provides  the  potential  for  t 
higher  degree  of  fidelity  than  do  more  aggregated 
techniques.  The  degree  of  detail  can  he  determined  oy 
the  modeler,  and  individual  subsystems  can  he  selectively 
aggregated  or  disaggregated  as  required. 

3.  It  allova  the  introduction  of  human  factors  considera¬ 
tions  at  the  level  at  vhich  they  naturally  occur.  In 
other  word*!,  individual  operator  actions  can  he  affected 
rather  than  sore  performance  measure  aggregated  over 
many  actions. 

The  SAIJT  simulation  language  has  been  selected  as  the  host 
language  for  the  MOPADS  operator  SK>dels.  SAIHT  is  an  acronym  for 
Systems  Analysis  of  Integrated  networks  of  Tasks.  It  was  initially 
developed  by  Pritsker  k  Associates,  Inc.  for  the  U.  S.  Air  Farce  to 
model  human  performance  in  man-machine  systems  and  has  had  numerous 
applications  including  modeling  of  operators  of  remotely  piloted 
vehicles. 

The  unique  feature  of  SAIHT  is  that  it  provides  a  formal  capa¬ 
bility  to  introduce  hitman  factors  considerations.  This  is  dome 
using  "moderator  functions"  vhich  modify  the  nominal  time  to  perform 
tasks.  The  modification,  of  course,  is  based  upon  the  operator's 
ability  to  perform  the  task  at  that  time.  Thus,  SAHIT  has  features 
vhich  make  it  immediately  useful  for  constructing  models  in  MOPADS. 

l»-0  MOPADS  TERMDfOLOGT 

The  remainder  of  this  report  discusses  the  above  topics  in 
greater  detail,  and  it  will  be  helpful  if  the  reader  familiarises 
himself /herself  with  the  "Standard  MOPADS  Terminology"  contained 
in  Table  1-1. 
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Table  1-1.  Standard  MOPADS  Termino?  og^ 


AIR  DEFENSE  SYSTEM 

A  cccponerrt  of  Air  Defense  which  includes 
equipment  and  operators  end  for  vbich 
technical  and  tectlcal  trailing  arerequlred. 
Examples  are  IHAVK  and  the  AS^SQ-73. 

AIR  DEFENSE  SYSTEM 
MODULE 

Models  of  operator  actions  and  equlpneot 
characteristics  for  Air  Defence  Systems  in 
the  MOPADS  software.  These  models  are  pre¬ 
pared  with  the  SAINT  simulation  language. 

Air  Defense  System  Modules  Include  the 

SAINT  model  and  all  data  needed  to  com¬ 
pletely  define  task  element  times,  task 
sequencing  requirements,  and  human  factors 
Influences. 

..  .  *  V 

AIR  SCENARIO 

A  spatial  and  temporal  record  of  aerial 
activities  and  characteristics  of  an  air 
defense  battle.  The  Air  Scenario  Includes 
aircraft  tracks,  safe  corridors,  ECM,  and 
other  aircraft  and  airspace  data.  8ee 
also  Tactical  Scenario. 

BRANCHING 

A  term  used  in  the  SAIlfT  simulation  lang¬ 
uage  to  mean  the  process  by  which  TASK  nodes 
are  sequenced.  At  the  completion  of  the 
simulated  activity  at  a  TASlf  node,  the 
Branching  from  that  node  determines  which 
TASK  nodes  will  be  simulated  next. 

DATA  BASE  CONTROL 
SYSTEM 

i 

That  part  of  the  MOPADS  software  which 
performs  all  direct  consnunication  with  the 
MOPADS  Data  Base.  All  information  transfer 
to  and  from  the  data  base  is  performed  by 
invoking  the  subprograms  which  make  up  the 
Data  BAse  Control  System. 

DATA  SOURCE 

SPECIALIST 

A  specialist  in  obtaining  and  interpreting 
Army  documentation  and  other  data  needed  to 
prepare  Air  Defense  System  Modules. 
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ENVIRONMENTAL 
STATE  VARIABLE 


An  element  of  an  Environmental  State 
Vector. 


ENVIRONMEI  TAL 

STATE  VECTOR 

An  array  of  values  representing  conditions 
or  characteristics  that  may  affect  more 
than  one  operator.  Elements  of  Environmen¬ 
tal  State  Vectors  may  change  dynamically 
during  a  MOPADS  simulation  to  represent 
changes  in  the  environment  conditions. 

MOOERATOR  FUNCTION 

A  mathematical/logical  relationship  which 
alters  the  nominal  time  to  perform  an  opera- 
tor  activity  (usually  a  Task  Element).  The 
nominal  time  is  changed  to  represent  the 
operator's  capability  to  perform  the 
activity  based  on  the  Operator's  State 
Vector. 

MOPAOS  DATA  BASE 

A  computerized  data  base  designed  specifi¬ 
cally  to  support  the  MOPADS  software.  The 
MOPADS  Data  Base  contains  simulation  Data 
8et(s).  It  communicates  interactively  with 
MOPADS  Uners  diving  pre-  and  post-run  data 
specification  and  dynamically  with  the  8AUIT 
software  during  simulation. 

MOPADS  MODELER 

An  analyst  who  will  develop  Air  Defense 
System  Modules  and  modify /develop  the 

N0PAD8  software  system. 

MOPAOS  USER 

An  analyst  who  will  design  and  conduct  simu¬ 
lation  experiments  with  the  MOPADS  software. 

MSAINT 

(MOPADS/SAINT) 

The  variant  of  SAINT  used  in  the  MOPADS 
system.  The  standard  version  of  SAINT  has 
been  modified  for  MOPADS  to  permit  share¬ 
able  subnetworks  and  more  sophisticated 
interrupts.  The  t  .-ms  SAINT  and  MSAINT  are 
used  interchangeably  when  no  confusion  will 
result.  See  also,  SAINT. 

OPERATOR  STATE 
VARIABLE 

OPERATOR  STATE 
VECTOR 

OPERATOR  TASK 

SAINT 

SIMULATION  DATA  SET 

!  SIMULATION  STATE 
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SYSTEM  MODULES 


TACTICAL  SCENARIO 


One  element  of  an  Oper  itor  State  Vector. 


An  array  of  values  represt ating  the  ocnCi- 
tion  and  chararterirtics  of  an  ojwrator  of 
an  Air  Defense  System.  Man)'  rallies  of  the 
Operator  State  Vector  will  change  dynamically 
during  the  course  of  a  MJPASS  simulation  to 
represent  changes  in  operator  condition. 


An  operator  activity  identified  during 
weapons  system  front-end  analyses. 


The  underlying  computer  simulation  language 
used  to  model  Air  Defense  Systems  in  Air 
Defense  System  Modules.  SAINT  is  an  acronym 
for  Systems  Analysis  of  Integrated  Hetvorks 
of  Tasks.  It  is  a  well  documented  language 
designed  specifically  to  represent  human 
factors  aspects  of  man /machine  systems. 

See  also  MSAMT. 


The  Tactical  Scenario  plus  all  required 
simulation  initialization  and  other  experi¬ 
mental  data  needed  to  perform  a  MDPAPS 
simulation. 


At  any  instant  In  time  of  a  MOPADS  simula¬ 
tion  the  Simulation  State  is  the  set  of 
values  of  all  variables  in  the  MOPADS  soft¬ 
ware  sad  the  MOPADS  Data  Base. 


See  Air  Defense  System  Modules. 


The  Air  Scenario  plus  specification  of 
critical  assets  and  the  air  defense  con¬ 
figuration  (number,  type  rad  location  of 
weapons  and  the  command  and  control  system) . 
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TACTICAL  SCENARIO 
COMPONENT 

An  element  of  a  Tactical  Scenario,  e.g.  , 

If  a  Tactical  Scenario  contain*  several 
Q-73's,  each  one  is  a  Tactical  Scenario 
Component. 

TASK 

See  Operator  Task. 

TASK  ELEMENTS 

Individual  operator  actions  which,  when 
grouped  appropriately,  sake  up  operator 
tasks.  Task  elements  are  usually  repre¬ 
sented  by  single  SAIBT  TASK  nodes  in  Air 
Defense  Systos  Modules. 

TASK  NODE 

A  modeling  symbol  used  in  the  BAHT  simula¬ 
tion  language.  A  TASK  node  represents  an 
activity;  depending  upon  the  modeling  cir¬ 
cumstances,  a  TASK  node  may  represent  an 
individual  activity  such  as  a  Task  Element, 
or  it  may  represent  an  aggregated  activity 
such  as  an  entire  Operator  Task. 

TASK  SEQUENCING 
MODERATOR 

FUNCTION 

A  mathematical/logical  relationship  which 
selects  the  next  Operator  Task  which  an 
operator  will  perform.  The  selection  is 
based  upon  operator  goal  seeking  character¬ 
istics. 
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NOPADS  HUMAN  FACTORS  MODELING 


1- 0  OVERVIEW  0?  HUMAS  FACTORS  U  MOPADS 

MOPADS  models  consist  of  networks  of  leaks,  and  eech  task,  is 
a  network  of  task  elements.  The  way  in  which  the  teaks  ore  con¬ 
nected  in  the  network  represents  potential  operator  decisions  cu 
sequencing  of  tasks.  Hunan  factors  will  affect  this  spates  la  two 
waps: 

1.  The  tine  to  perform  task  elements  is  affected 

( "moderates")  by  environmental  and  operator  conditions. 
Thus,  the  values  of  independent  variables  such  as  lack 
of  sleep,  hours  of  :~ntinuou*  duty,  amount  of 
training,  and  tracking  ability  as  well  as  environmental 
variables  such  as  ambient  temperature  say  affect  the 
time  required  to  perform  tasks. 

2.  The  order  in  which  the  operator  performs  operator 
tasks  will  be  determined  by  the  degree  which  a  parti¬ 
cular  task  will  help  to  satisfy  the  operator's  goals. 
When  a  task  is  completed,  the  operator  will  evaluate 
the  state  of  each  goal  and  estimate  the  impact  on  these 
goals  from  the  vari  ms  options  at  hand.  A  task  will 
be  selected  based  on  the  operator's  objective  and  his 
estimates  of  the  probable  goal  improvement. 

2- 0  TASK  ELDEST  MODERATOR  rUHCTlOHS 

2-1 .  The  MOPAPS  Ski J Is  Taxonomy . 

As  discussed  earlier,  task  elements  are  generally  the 
lowest  level  of  activity  described  in  Army  documentation.  Since 
these  actions  are  directly  observable,  it  is  relatively  easy  to 
obtain  estimates  of  the  nominal  time  to  perform  them.  Such  times, 
however,  will  be  estimates  of  the  "nominal"  time  under  average 
conditions  and  by  average  operators.  In  order  to  systematically 
estimate  the  effect  on  operator  performance  of  environmental  and 
scenario  specific  conditions,  the  task  element  performance  times 
must  be  known  as  functions  of  these  variables. 

MOPADS  uses  the  concept  of  a  "moderator  function"  to  accom¬ 
plish  this.  The  moderator  functions  accept  the  nominal  task  element 
performance  time  and  alter  it  ("moderate  it”)  based  on  endogenous 
and  exogenous  environmental  variables.  In  this  way,  an  operator's 
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performance  is  affected  dynam  '.cally  during  the  simulation  by  the 
changing  conditions  of  the  sy&te*.  A  major  activity  of  the  M0FAE6 
project  has  been  the  development  of  the  moderator  functions.  Single 
observations  of  operators  is  not  a  practical  method  to  obtain  such 
functions  because  of  the  man}  variables  and  conditions  that  would 
need  to  be  controlled. 

Consider  the  action  of  un  AK/TSQ-73  operator.  There  are 
literally  dozens  of  task  elements  which  this  operator  performs.  It 
vould  be  a  prohibitively  expensive  chore  to  develop  separate  modern* 
tor  functions  for  each  task  element.  To  do  so  vould  require  that 
operators  be  observed  performing  each  task  element  under  controlled 
conditions  while  varying  the  independent  variables  of  interest.  Then 
the  data  vould  need  to  be  reduced  to  a  functional  form  suitable  for 
use  in  M0PAD6  models. 

A  moderator  function  approach  was  needed  that  vould  be  generic 
in  nature.  In  other  words,  one  that  vould  be  applicable  to  more  than 
one  task  element.  The  approach  selected  was  to  consider  each  task 
element  as  an  activity  that  requires  one  or  more  operator  skills.  The 
human  factors  literature  contains  a  good  deal  of  data  on  how  skill 
performance  varies  with  a  vide  variety  of  independent  variables.  The 
idea  was  to  develop  skill  moderator  functions  for  the  skills  required 
by  air  defense  operators,  and  then  to  combine  these  functions  according 
to  the  skills  required  for  a  particular  task  el  eaten t  to  obtain  a  com¬ 
bined  moderator  tailored  for  the  task  element.  A  skills  taxonomy  simi¬ 
lar  to  the  one  presented  in  Finley,  Oberaeyer,  Bert one,  Meiater,  A 
Muckier ( 1970 )  was  selected  since  it  includes  skills  required  by  sir 
defense  operators.  It  is  shown  in  Table  II-l. 

Moderator  functions  for  each  of  these  skills  have  been 
developed.  Each  of  the  operator  task  elements  is  considered  to 
require  s  combination  of  one  or  more  of  the  skills  shewn  in 
Table  II-l.  A  moderator  function  for  a  particular  task  element 
is  evaluated  by  combining  the  moderators  for  the  component  skills 
as  explained  in  Section  2-2  below.  Is  this  way,  moderators  for  a 
vide  variety  of  air  defense  operator  actions  are  available  from  a 
relatively  small  set  of  skill  moderator  functions. 

The  skill  moderator  functions  were  developed  from  the  open 
human  factors  literature.  The  following  five  steps  were  performed 
to  develop  them. 
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Table  11-1.  MOPADS  Skills  Taxoncoy 


,  1 

Probability  Estimation 

2 

Time  Estimation 

3 

Long  Term  Memory-Sensory 

k 

Long  Term  Memory-Symbolic 

> 

Short  Tent  Memory-Sensory 

6 

Short  Term  Memory-Symbolic 

7 

Huneric  Manipulation 

8 

Recognition 

9 

Unused 

10 

Unused 

11 

Timeshrring 

12 

Detection 

13 

Fine  Manipulation 

Ik 

Gross  Manipulation 

15 

Unused 

16 

General  Physical  Effort 

17 

Reaction  Time 

18 

Tracking 

19 

Team  Coordination 

t 


1.  Literature  Reriev 

2.  Development  of  a  Computer  Data  Base 

3.  Selecting  Independent  Variables 

k.  Developing  Moderator  Functions 

5.  Cross-checking  the  Moderator  Functions  with  a 

Structural  Model  of  the  Human 
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Since  the  moderator  functions  are  to  refelct  the  current 
state-of-the-art  in  quantitative  human  performance  modeling,  the 
first  step  vas  to  review  the  current  literature.  This  vas 
couplet ed  and  documented  in  Laughery  ( 1981a).  The  next  step  vas 
to  organize  this  literature  in  a  meaningful  way.  One  part  of  the 
organization  was  already  defined  by  the  skill  categories.  Each 
human  performance  model  in  an  article  vas  categorized  by  the  skill 
it  modeled.  In  sane  cases  the  model  grouped  several  skill  categories 
(e.g. ,  detection  and  identification).  In  this  evmt,  it  vas  assigned 
to  sniltiple  skill  categories.  Secondly,  a  model  within  an  article 
could  he  characterized  hy  the  independent  variables  which  moderated 
performance  of  the  skill.  By  compiling  these  "data"  cm  the  litera¬ 
ture,  it  vas  possible  to  select  all  articles  involving!  a  particular 
skill  and  examine  the  independent  variables  included  in  the  models. 


To  facilitate  rapid  analysis  of  the  literature  data  base,  a 
set  of  computer  programs  and  files  for  data  base  management  vere 
prepared  (Laughery,  1981b ) .  As  the  literature  vas  reviewed  and  the 
data  entered  into  the  data  base,  no  screening  vas  performed  on  the 
information.  In  other  vdnds,  each  time  a  new  independent  variable 
vas  encountered,  it  vas  added  to  the  list  of  variables.  The  extent 
of  the  literature  seviev  vas  constrained  by  resources  abd  time  avail¬ 
able  and  by  the  skill3  taxonomy  vhich  bounded  the  set  bf  pertinent 
literature.  The  entire  data  base  and  the  data  base  programs  have 
been  delivered  to  the  government  for  further  developemht  if  warranted. 

Vhen  the  literature  search  vas  complete,  it  vas  necessary  to 
reduce  the  information  collected  to  a  coherent  set  of  moderator  func¬ 
tions.  Hot  all  of  the  independent  variables  represented  in  the  data 
base  would  be  relevant  to  MOPADS,  and  the  issue  of  "sufficiency" 
needed  to  be  addressed.  In  other  words,  vas  the  set  of  Independent 
variables  sufficient  to  m^del  air  defense  operators. 


Some  type  of  cross-check  was  required.  Relying  solely  on  the 
literature  to  identify  which  Independent  variables  affect  skills 
assumes  that  all  relationships  have  been  studied  and  reported  in  the 
open  literature.  Since  this  is  surely  not  the  case,  a  conceptual 
model  of  the  human  vas  developed  from  a  slightly  different  perspective 
(Laughery  &  Dltzian,  1981).  Rather  than  treating  the  human  as  a 
performer  of  different  types  of  skills,  a  model  vas  developed  of  the 
human  with  respect  to  functional  systems  (e.g.,  visual,  auditory, 
memory).  Those  human  systems  involved  in  each  skill  category  from  the 
taxonomy  vere  then  intuitively  identified  and  arrayed  into  a  "human 
system"  by  "skills"  matrix.  £1  the  list  of  independent  variables  vas 
developed,  those  independent  variables  vhich  vere  intuitively  expected 
to  interact  with  the  hirnan  systems  vere  identified  and  documented  in 
a  "human  systems"  by  "’independent  variables"  matrix,  finally,  a  list 
of  hypothesized  independent  variables  vas  linked  to  every  skill  by 
crossing  the  "human  systems"  by  "skills"  matrix  with  the  "independent 
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variables"  by  "human  cyst  or"  mi-trix,  resulting  in  an  "independent 
variables"  by  "skill  categories  matrix.  This  matrix  was  compared 
with  the  moderator  functions  for  each  skill  category  to  see  if  all 
theoretically  related  Independent  variables  were  included. 

Premising  articles  ir.  the  data  base  were  examined  in  greater, 
detail  and  thiir  performance  models  compared  with  the  intuitive  human 
function  model.  Two  articles  that  significantly  affected  the  final 
model  were  Siegel,  Pfeiffer*  Kopstein,  Wilson ,  & Ozkaptan  ( 19 f9 )  and 
Pew,  Baron,  Seehrer,  &  Miller  (1977).  The  final  set  of  independent 
variables  for  MOPADS  is  shown  in  Table  11-2. 


The  three  categories  of  independent  variables  specify  the 
scope  of  each  category  of  variables.  Operator  variables  constitute 
the  operator's  state  vector.  Each  operator  has  his  cam  Bet  of  values 
for  these  variables. 

The  environmental  variables  form  the  environmental  state 
vector.  These  variables  affect  all  operators  in  the  same  environ¬ 
ment.  For  example,  both  operators  in  an  AN/TSQ-73  are  affected  by 
the  same  environmental  state  vector.  Finally,  task  variables  apply 
to  any  operator  that  performs  the  task,  and  each  task  has  its  own 
set  of  values  for  each  of  the  variables. 

Obviously,  some  of  the  ‘independent  variables  do  not  apply  to 
operators  of  the  AN/TSQ-73  and  XHAWK.  They  have  been  included, 
however,  because  the  objective  in  developing  the  taxonomy  was  to 
characterize  the  skill  requirements  of  most  air  defense  operators. 
Thus,  MOPADS  can  be  expanded  at  a  later  time  to  include  other  air 
defense  systems  such  as  Redeye,  Vulcan,  etc.  All  of  the  independent 
variables  shown  in  Table  II-2  have  been  implemented  in  the  current 
MOPADS  software.  Since  only  the  AN/TSQ-T3  and  IHAWK  are  modeled, 
however,  not  all  of  the  variables  are  used.  This  causes  no  difficulty 
in  the  present  models,  but  it  will  greatly  facilitate  future 
expansions. 

2-2 .  Computation  of  Combined  Task  Element  Moderator  Functions . 

The  current  implementation  of  the  MOPADS  skill  moderator 
functions  affect  only  the  mean  task  element  time.  The  software  has 
been  developed  in  such  a  way  that,  if  at  some  time  appropriate  data 
become  available,  then  the  standard  deviation  and  distribuxion  func¬ 
tion  can  also  be  moderated. 

Consider  the  operator  task  shown  in  Figure  II-l  for  the 
AN/TSQ-73,  and  the  aggregate  SAINT  task  model  shovn  in  Figure  II-2. 

The  trapezoids  labeled  wo)  in  Figure  II-l  corresponds  to  the  SAINT 
"task  node"  numbered  1*8  (with  LABL:  NUMHOOK)  in  Figure  II-2.  Task 
node  U8  in  Figure  II-2  is  the  SAINT  modeling  symbol  that  corresponds 
to  the  task  elements  "ENTER  TRACK  NUMBER,  FIRE  UNIT,  OR  SITE  ADDRESS 
ON  A/N  KEYBOARD"  and  "PRESS  TASK  FUNCTIONS-NUMBER  HOOK". 
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Table  II 


OPERATOR 


■2.  MOPADS  Independent  Variables. 


STATE  VARIABLES 

CORE  TEMPERATURE 

CIO  VALUE 

TIME  ON  TASK 

DAYS  OF  DUTY 

SEARCH  DIMENSIONS 

NUMBER  FIRE  UNITS 

PERCENTAGE  RECOVERY 

PREVIOUS  WORK 

PREVIOUS  REST 

FLASH  INTENSITY 

TARGET  SPEED 

TARGET  TYPE 

TARGET  SIZE 

TARGET  COLOR 

SEARCH  AREA 

BINOCULAR  USAGE 

SLANT  RANGE  TO  TARGET 

TARGET  TRAJECTORY 

TARGET  BACKGROUND  COMPLEXITY 

NUFBER  BACKGROUND  CHARACTERS 

MESSAGE  BACKLOG 

SIGNALS  PER  MINUTE 

HOURS  WORKED  PER  WEEK 

DAYS  WITHOUT  SLEEP 

DAYS  OF  NIGHT  DUTY 

SIMULTANEOUS  TASKS 

CONTRAST  RATIO 

AVERAGE  HOURS  SLEEP 

OBJECTIVE  FUNCTION 

GOALS  CONSIDERED 

TARGET  BRIGHTNESS 

NIGHTS 

SKY  GROUND  RATIO 

AIRCRAFT  ALTITUDE 

METEOROLOGICAL  RANGE 

THRESHOLD  CONTRAST 

TARGET  HEIGHT 

TARGET  WIDTH 

TARGET  DEPTH 

HORIZONTAL  RANGE 

NUMBER  OF  RESOLUTION  ELEMENTS 

NUMBER  OF  SUSPECT  AREAS 

AIRCRAFT  SPEED 

FIELD  OF  VIEW 

OBSERVER  OFFSET 


Table  II-2  (continued) 


46  DISPLAY  TARGET  LOCATION 

47  TARGET  LOCATION 

48  Di SPLAY  RESOLUTION 

43  DT SPLAY  BACKGROUND  HEIGHT 

50  DISPLAY  BACKGROUND  WIDTH 

51  DISPLAY  BACKGROUND  DEPTH 

52  DISTANCE  TO  DISPLAY 

53  DISPLAY  HEIGHT 

54  DISPLAY  WIDTH 

55  TARGET  NOISE  LEVEL 

56  TARGET  DURATION 

57  EXPERIENCE 

58  SIGNAL  PROBABILITY 

59  REST  PERIODS 

60  DAYS  SINCE  PRACTICE 

61  SENSE  OF  DIRECTION 

62  SKIN  TEMPERATURE 

63  TIME  IN  TEMPERATURE 

64  PREVIOUS  SKIN  TEMPERATURE 


ENVIRONMENTAL  VARIABLES 

1  DRY  BULB  TEMPERATURE 

2  RELATIVE  HUMIDITY 

3  AIR  MOVEMENT  RATE 

4  NOISE  LEVEL 

5  WORK  AREA  ILLUMINATION 

6  NUMBER  ON  DUTY 

7  VIBRATION 

8  AMBIENT  VAPOR  PRESSURE 

9  NOISE  PREDICTABILITY 


TASK  RELATED  VARIABLES 

1  KI LOCALORI ES/MINUTE 

2  NUMBER  OF  BRANCHES  OUT 

3  *  STIMULUS  MODE  1 

4  *  STIMULUS  MODE  2 

5  *  RESPONSE  MODE 

6  *  OBSERVER  TARGET  POSITION 

7  CONTROL  DISTANCE 

8  CONTROL  WIDTH 

9  NUMBER  OF  DISPLAYS 

10  NUMBER  OF  ALTERNATIVES 

11  NUM5ER  SHORT  TERM  MEMORY  ITEMS 


*  See  Legend 
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Table  II -2  (continued) 


legend 


Stimulus  Mode  1 

A  two-digit  number 

10's  digit  -  0  -  no  visual 
.1  -  visual 

I's  dlgH  0  -  no  auditory 
1  -  auditory 

Stimulus  Mode  2 

A  three-digit  number  as  above 
100‘s  digit  -  0  -  no  olfactory 
1  -  olfactory 

10's  digit  0  -  no  kinesthetic 
1  -  kinesthetic 
l's  digit  0  -  no  tactile 
1  -  tactile 

Response  Mode 

A  two-digit  number 

10's  digit  -  0  -  no  vocal 
1  -  vocal 

l‘s  digit  0  -  no  tactile 
i  -  tactile 

Observer  Target  Position 

1  -  ground  to  ground 

2  -  air  to  ground 

3  -  ground  to  air 

4  -  air  to  air 

5  -  at  a  display 
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Fixttre  4-14.  Console  Hooking  Procedures  -  S umber,  CEOREF,  mul  Position  Hook 


Figure  II-l.  M/TSQ-73  Console  Hooking  Procedures. 
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8ample  data  for  this  taak  element  arc  shown  belcw: 


nominal  Mean  Tine: 

k.|>  seconds 

Skills  Required: 

Fine  Manipulation 

75 ? 

Short-Term  Memory- 

15? 

Symbolic 

• 

Detection 

10? 

During  a  MOPADS  simulatira,  when  an  operator  la  to  perform  this 
task  element,  MOPADS  will  call  the  moderator  functions  for  the 
three  akilla  shown  abo/e.  The  moderator  functions  here  access  to 
the  information  in  the  operator  state  vector,  the  environmental 
state  vector,  and  the  task  data.  With  this  information,  the  aoder¬ 
ator  functions  will  each  compute  a  change  to  the  mean  of  it. 5  seconds. 

Let  D.,  D_,  and  D,  be  the  computed  changes  from  the  aoderator 
functions  for  fine  manipulation,  short -ten*  menory-ayabolic ,  and 
detection,  respectively.  See  Laugh ery  l  Ditzian  (1982)  4  Laughery 
(1981)  for  these  skill  moderator  functions.  The  combined  mean  is 
determined  from 

•  M  ♦  (.75^  ♦  .15Dj  .  .10D3) 


The  obvious  interpretation  is  that  approximately  75?  of  the  time 
performing  the  task  element  is  in  fine  manipulation,  etc.,  and  minimal 
interaction  between  skills  occurs.  In  the  absence  of  data,  these 
are  relatively  mild  assumptions  to  achieve  computable  moderators 
for  a  vide  variety  of  activities. 

The  moderated  mean  say  then  he  used  in  the  simulation  to  deter¬ 
mine  the  tine  required  for  the  operator  to  perform  the  task  element. 
MCPAD8  allows  several  options  in  this  regard: 


1.  Deterministic,  unmoderated 

2.  Deterministic,  mod -rated 

3.  Stochastic,  unao derated 


k.  Stochastic,  moderated 


always  use  the  nominal 

mean  time 


“*  ^Moderated  tar 

task  element  time 


make  a  random  draw  from 
the  specified  distribu¬ 
tion  function  whose 
mean  ia  the  nominal 
mean.  Do  not  use  the 
moderator  functions. 


-  make  a  random  draw 
from  the  specified 
distribution  function 

1.  Vd„rttl 
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HOPAK  supports  tbs  following  distribution  functions: 
Constant 
Xomal 
Uniform 

Erlang  -1  (Exponential) 

Lognormal 

Beta 


The  Caana  distribution  is  the  default  distribution,  but  the  user  can 
select  any  of  the  above. 

2- 3.  Software  Implementation. 

As  stated  earlier,  the  human  factors  moderator  function 
module  has  been  developed  in  a  way  that  allows  it  to  be  separated 
from  the  rest  of  the  M0PAE6  software  and  used  independently.  This 
has  been  accccnpli shed  through  the  following  design  considerations: 

1.  Every  moderator  function  subprogram  has  an 
identical  calling  sequence. 

2.  Moderator  functions  request  data  from  the 
operator  state  vectors,  environmental  state 
vectors,  and  the  task  data  through  standard 
subprogram  calls. 

The  implication  of  the  above  are  that  nan-MOPADS  software  environ¬ 
ments  can  use  the  moderator  functions  by  calling  them  in  their  stan¬ 
dard  way  and  by  providing  utility  programs  that  the  moderator  functions 
will  call  to  access  operator,  environmental,  and  task  data.  HOFADS  docu¬ 
ments  Laughery  A  Ditzitn  (1962)  A  Laughery  (1981)  contain  the  technical 
details. 

3-o  tass.  3*qunfcmc  methodology 

3- 1.  Task  Sequencing  Considerations. 

In  order  to  adequately  model  the  actions  of  an  air 
defense  operator,  the  simulation  must  "perform"  operator  tasks  in  a 
way  that  responds  to  the  air  defense  scenario.  In  other  words,  the 
simulated  operators  must  perform  tasks  that  tend  toward  accomplishing 
the  mission  of  the  air  defense  system.  Developing  a  methodology  that 
will  exhibit  this  behavior  is  more  difficult  thun  simulating  the 
operator  tasks,  because  the  simulation  must  represent  the  knowledge, 
experience,  and  motivations  of  the  operators. 
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Furthermore,  the  simulation  w»thodole>s/  needs  to  be  accessible 
to  the  user.  In  other  words ,  input  parameters  for  the  task 
sequencing  algorithm  should  be  intuitively  meaningful  and  reasonably 
easy  to  determine.  With  these  ideas  in  mind,  the  objectives  in 
developing  a  task  sequencing  procedure  were  as  follows: 

The  procedure  should  be: 

1.  consistent  with  the  literature, 

2.  intuitively  meaningful  to  that  a  MOPADS  analyst 
can  specify  operator  oriented  parameters 
rather  than  abstract  parameters  that  a re 
obtained  from  some  curve  fitting  procedure,  and 

3.  relatively  goal  independent.  This  means  that 
the  parameters  associated  with  one  operator 
objective  are  nearly  independent  of  the  para¬ 
meters  associated  with  all  other  objectives. 

Utility  function  and  goal  spiking  approaches  were  considered. 

The  multi -attribute  utility  function  procedure  was  discarded 
because  it  did  not  satisfy  objectives  (2)  and  (3)  above.  A  goal 
seeking  approach,  on  the  other  band,  can  be  implemented  in  a  way 
that  satisfies  (2)  and  (3)  above  and  is  consistent  vlth  the  Newell  A 
Simon  (1972}  view  of  humans  as  goal  seekers.  The  principal  advantage 
of  the  goal  seeking  approach  is  that  the  utility  or  "goal  priority" 
of  each  goal  can  be  computed  independently  of  all  other  goals  (this 
of  course,  is  an  assumption  but  a  relatively  mild  one). 

In  particular,  goal  priority  functions  can  be  defined  that  are 
ordinal  in  nature,  so  that  changes  in  parameters  for  one  goal  do  not 
affect  the  parameters  of  other  goals.  The  priority,  or  degree  of 
goal  satisfaction,  for  each  goal  can  then  he  compared.  This  is  in 
contrast  to  a  multi-attribute  utility  approach  in  which  a  cardinal 
utility  value  is  computed  as  a  function  of  all  goal  states.  The 
usual  approach  in  utility  theory  is  to  develop  a  utility  function 
of  several  variables  (the  goal  states)  from  a  curve  fitting  pro¬ 
cedure.  This  is  a  cumbersome  method  for  use  in  MOPADS  because  changes 
to  individual  goals  for  individual  operators  cannot  be  easily  incor¬ 
porated  into  the  model. 

3-2.  The  Task  Sequencing  Procedure. 

The  goal  seeking  behavior  of  the  operators  is  charac¬ 
terized  by  the  following: 

1.  The  operators  have  a  set  of  goals  which  they  desire 
to  satisfy  simultaneously.  They  are  capable  of 
determining  the  value  or  state  of  each  goal.  For 
example,  the  operator  may  desire  to  maximize  the 
distance  from  a  critical  asset  to  any  hostile  air¬ 
craft.  The  goal  state  is  the  minimum  distance  to 
any  hostile  track. 
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2.  The  operators  can  rank  the  importance  of  their 
goal  states.  In  other  words,  they  can  assign 
priorities  to  their  goals  based  upon  their 
current  states.  For  example,  an  AH/TSQ-73 
operator  can  determine  whether  an  uncleared 
alert  nessage  or  a  hostile  aircraft  within  30 
miles  of  r  critical  asset  should  be  attended 
to  next . 

3.  The  operators  are  capable  of  estimating  the 
changes  t  int  will  occur  in  their  goal  states  if 
a  particular  task  is  performed. 

h.  Operators  are  limited  in  their  ability  to 

satisfy  their  goals.  They  may  not  be  able  to 
consider  all  of  their  goals  at  once. 

These  concepts  are  implemented  In  the  following  ways.  For 
each  operator  goal,  the  goal  state  (denoted  GS)  must  be  explicitly 
specified  in  s  way  that  allows  GS  to  be  assigned  a  unique  value 
(e.g. ,  GS  «  the  number  of  unassigned  hostile  tracks).  Then  a  goal 
priority  function,  GF,  is  specified  for  the  goal  that  assigns  a 
non-negative  value  to  each  value  of  GS.  Figure  II-3  shows  an 
K  f  hypothetical  example.  The  goal  is  satisfied  when  the  god  state, 

GS,  is  between  m  and  N.  This  is  signified  by  GF  ■  0  when 
m  <_  GP  £  M.  If  the  god  state  is  less  than  m  or  greater  than  M, 
then  the  priority  of  the  god  (l.e.,  its  degree  of  dissatisfaction) 
increases  linearly. 

The  meaning  of  the  particular  god  priority  function  in 
Figure  II-3  is  that  the  operator  is  satisfied  and  indifferent  to  any 
value  of  the  goal  state  between  m  and  M.  Downside  deviations  (l.e., 
values  of  GS  less  than  m)  are  more  important  than  upside  deviations 
(l.e.,  vdues  of  GS  greater  than  N)  since  the  slope  for  downside 
deviations  is  greater  than  the  slope  for  upside  deviations. 

Each  goal  that  an  operator  has  may  have  a  different  priority- 
function  •  See  Figure  IT— I*  for  examples.  The  vdues  of  the  god 
priorities  for  each  god  are  compared  in  an  ordinal  fashion  during 
task  sequencing  to  determine  the  most  dissatisfied  god  or  goals. 
This  scheme  allows  the  parameters  for  a  god  priority  function  to 
be  specified  or  changed  without  affecting  the  priority  functions 
for  other  gods.  Of  coursa,  complete  independence  is  cot  obtained 
because  the  modeler  must  always  be  aware  of  the  priority  functions 
of  the  rest  of  the  gods. 

Determination  of  the  gods  and  the  god  priority  functions 
must  be  accomplished  vith  close  coordination  with  subject  matter 
experts  since  no  open  literature  is  available.  Recall  that  the 
operators  will  select  tasks  in  order  to  improve  their  god  states. 
Therefore,  the  modeler  must  specify  one  or  more  gods  whose  states 
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•re  affected  by  each  task.  Goal  priority  functions  say  be  deter* 
mined  by  giving  pairwise  comparisons  to  subject  matter  experts 
(e.g.,  given  states  for  tvo  goals,  which  -joal  would  have  the  hipest 
priority?).  Since  the  scale  of  the  goal  priority  is  arbitrary,  the 
modeler  can  ordinally  rank  the  responses  to  achieve  correct  rankings 
of  the  goals.  In  the  current  MOPADS  implementation;  a  goal  priority 
of  10  has  been  uted  t.~  imply  an  extreme  emergency,  so  30 al  priority 
values  generally  fall  in  the  range  zero  to  10. 

The  operators  seek  to  achieve  one  of  the  following  two 
objectives  when  selecting  the  next  task. 

1.  Maximize  the  expected  reduction  in  the  average  goal 
priority  of  the  IG  largest  goal  priorities. 

2.  Maximize  the  expected  reduction  per  unit  time  of  the 
average  goal  priority  of  the  HG  largest  goal 
priorities. 


GS  -  Goal  State 
GP-  Goal  Priority 


GS 


Figure  II-3.  Example  Goal  Priority  Function. 
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In  the  first  case,  the  operator  computes  ths  average  goal 
priority  of  the  NG  most  dissatisfied  goals.  HG  is  a  parameter  of 
the  operator  vhich  may  he  set  by  the  MOPADS  user.  Uote  that  if 
HG  is  ones  the  operator  "puts  out  the  biggest  fire  first."  As  HG 
increases,  the  operator  is  modeled  as  being  able  to  take  a  more 
and  more  global  viev  of  his  tasks.  At  the  present  time,  HG 
remains  fixed  for  each  operator  during  the  entire  simulation.  If 
relevant  data  were  available,  it  would  be  possible  to  dynamically  vary 
HG  in  response  to  operator  work  load  or  other  conditions  during  the 
simulation. 

The  second  objective  function  is  similar  to  the  first,  but, 
in  addition,  the  operator  estimates  the  time  it  will  take  to  per¬ 
form  each  option  available.  With  this  information,  the  operator 
estimates  the  change  in  average  goal  priority  that  will  occur  per 
unit  time  and  selects  the  one  which  gives  the  most  rapid  improvement. 

Finally,  a  last-in-first-out  task  stack  is  maintained  for 
each  operator.  Sane  options  available  to  the  operator  may  involve 
performing  several  operator  tasks  before  re-evaluating  goals  again. 
For  such  a  case,  the  tasks  which  will  be  performed  in  sequence  are 
loaded  in  the  r per at or 'a  task  stack.  When  one  task  is  completed, 
the  operator  will  immediately  perform  the  next  task  an  his  stack. 

Goal  evaluation  is  performed  only  when  the  stack  is  empty  or  a  hied1 
priority  alert  message  has  been  received.  In  the  case  of  a  high 
priority  message,  *  complete  goal  evaluation  occurs. 

The  procedure  for  goal  evaluation  and  task  selection  is  shown 
in  Figure  II-5-  The  special  weighted  average  of  the  god  priorities 
is  computed  as  follows  (here  assume  that  the  goal  priorities  have 
been  arranged  in  decreasing  order). 


AVHG  ■ 


where 


Thus,  the  maximisn  weight  is  given  to  the  most  dissatisfied  goal 
(i.e.,  the  one  with  the  largest  goal  priority).  This  method  pre¬ 
vents  certain  distortions  in  task  selection  that  might  result 
from  the  use  of  a  simple  average.  For  example,  suppose  the  two 


► 
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1.  If  th*  task  stack  Is  not  empty  and  no 
higher  priority  message  Is  pending, 
then  select  the  next  task  from  the 
task  stack  and  exit. 


2.  Otherwise, 


a)  evaluate  each  goal  state, 

b)  evaluate  each  goal  priority  function 

c)  compute  the  weighted  average  goal  priority 

d)  For  each  alternative  task  selection  - 

1)  compute  the  expected  goal  states. 

If  the  task  Is  performed 

11)  compute  the  expected  goal  priorities 

111)  compute  the  expected  average  goal 
priority 

e)  select  the  task  that  best  improves  the 
operator's  objective  function 

f)  load  the  task  stack  If  necessary,  and 
9)  «x1t 


Figure  II-5.  Coal  Evaluation  Procedure. 


* 


Boat  disB&ticf'ed  goals  (with  gG  ■  2)  are  (GP. ,  GP_)  ■  (10,5).  The 
simple  average  goad  priority,  X,  is  7.5  while1  AVNG*  8.32- 
(v.  •  .67,  v?  »  .33).  Suppose  there  aure  two  options  whose  expected 
results  are  shown  below  (the  aure  not  recomputed) . 

# 

GP1  GPg  X  AVBG 

Option  1  10  1  5.5  7.0 

Option  2  6  5  5.5  5.67 

The  simple  average  of  the  goal  priorities  is  Indifferent  to  the  tvo 
options  since  they  both  result  in  a  reduction  of  four  in  the  sum 
of  the  goal  priorities.  Option  1,  however,  makes  no  improvement  in 
the  most  dissatisfied  goal.  Selection  of  option  1  would  represent 
an  operator  who  attempts  to  improve  the  second  most  dissatisfied 
goal  when  there  is  an  available  option  that  improves  the  most 
dissatisfied  goal.  Using  the  speciad  weighted  average  AVNG  ensures 
that  the  operator  will  always  pay  most  attention  to  the  most  dis¬ 
satisfied  goads  even  though  he  is  attempting  to  consider  more  than 
one  goad  simultaneously. 

Finally,  note  that  the  goal  seeking  procedure  explained  above 
is  a  simplified  special  case  of  utility  theory.  The  utility  func¬ 
tion  is  simply  a  composition  of  the  univauriate  goal  priority  func¬ 
tions  which  aure  combined  through  the  AVHG  function  to  a  single 
value  for  each  set  of  goad  states.  It  would  be  a  simple  matter  to 
recast  the  mathematical  expression  of  the  procedure  in  a  utility 
theoretic  framework.  The  goal  seeking  method  simply  assumes  that 
a  utility  surrogate(the  goad  priority)  caua  be  expressed  as  a  function 
of  a  subset  of  the  set  of  the  goad  states  (i.e.,  the  priority  of  a 
goad  is  a  function  only  of  its  own  goad  state). 

3-3.  Operator  Goals  for  the  AN/TSQ-73  and  IEAWK. 

The  goals  identified  for  the  operators  of  the  AH/TSQ-73 
and  the  IHAVK  arise  from  the  basic  goads  of  self  preservation  and  a 
desire  to  accomplish  their  mission.  The  translation  of  these  basic 
goads  to  operative  goal  statements  results  in  goals  that  lead  the 
operators  to  attack  aircraft  that  present  threats  to  themselves  and 
the  sites  they  are  assigned  to  protect  and  to  follow  standard  pro¬ 
cedures  to  au:c7mplish  their  missions.  The  statements  of  the  goals 
for  the  AN/TSQ-73  amd  IHAWK  operators  are  shown  in  Tables  II-3  and  Il-fc 
respectively. 

3-*».  Software  Implementation  of  Task  Sequencing. 

As  is  the  case  in  all  of  the  MOPADS  software  designs,  the 
structure  is  intended  to  allow  for  future  expansions  (see  Figure  II-6). 
The  common  programs  include  those  parts  of  the  task  sequencing 


Table  Il-3  (continued) 


Table  II-4.  Operator  Goal  for  the  IHAWK. 
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procedure  that  are  independent  of  the  systoi  module  and  operator 
type.  This  includes  statistics  collection*  branching,  and 
certain  utility  programs.  Each  system  module  (designated  SMI,  91% 
etc.  in  Figure  II-6)  has  its  own  entry  point  subprogram  which 
will,  in  turn,  call  a  program  to  process  the  goals  for  each  opera¬ 
tor  type  in  the  system.  The  task  sequencing  programs  labeled  SML, 
SM2,  etc.  and  their  descenderts  are  documented  as  part  of  the 
system  module  documentation.  In  this  vay,  new  system  modules  can 
he  added  by  "plugging  in"  the  task  sequencing  programs  without 
disturbing  existing  system  modules. 


OPERATOR  1  OPERATOR  2  OPERATOR  3 


Figure  II -6.  Schematic  Structure  of  MO  PADS  Task  Sequencing 
Software. 
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Ill,  MOPADS  AIR  DEFENSE  MODELS 


1-0  DEVELOPMENT  ME3T0D0L0GY  FOR  AIR  DEFENSE  SYSTEM  MODULES 

MOPADS  is  intended  to  fee  a  long  lived  software  system  that 
will  evolve  as  nev  system  modules  are  developed.  Since  the  develop¬ 
ment  of  system  modules  is  the  most  complex  maintenance  activity  that 
will  fee  performed  on  MOPADS  and  since  it  is  likely  that  many  indivi¬ 
duals  will  fee  involved  in  developing  the  modules,  it  is  essential 
that  a  systematic  development  and  documentation  methodology  fee 
followed.  Procedures  for  these  activities  have  feeen  created 
(Walker  &  Polito,  1982a,b). 

The  procedure  for  developing  system  modules  is  sunmarlzed  in 
Figure  III-l.  Steps  1,  2,  and  3  are  data  collection  functions  in 
which  the  MOPADS  analyst  and  those  who  aid  him/her  collect  informa¬ 
tion  and  systematically  characterize  operator  and  equipment  model¬ 
ing  requirements.  In  steps  k,  5,  and  6,  task  sequencing  considera¬ 
tions  and  constraints  are  identified  and  formalized.  Human  factors 
are  minimally  or  nominally  represented  at  this  stage.  The  purpose 
is  to  ensure  that  infeasible  or  unrealistic  sequencing  does  not 
occur. 


At  step  11,  the  MOPADS  modeler  enters  data  for  the  nev  system 
module  into  the  MOPADS  data  base.  The  MOPADS  user  interface  has 
facilities  to  support  this  activity.  At  step  12,  the  MOPADS  simu¬ 
lations  are  performed  with  a  minimal  set  of  existing  MOPADS  models 
to  test  the  new  system  module.  When  this  is  completed,  the  new 
system  model  is  integrated  with  the  full  set  of  existing  MOPADS 
models  and  tested.  These  are  steps  13  and  lk. 

Step  15  is  the  final  documentation  effort.  A  systematic  pro¬ 
cedure  for  documentation  has  feeen  specified  to  aid  in  module  develop¬ 
ment  and  to  ensure  that  adequate  documentation  of  system  modules  is 
maintained.  This  is  crucial  because  it  is  certain  that  when  a  new 
module  is  developed,  the  analyst  will  have  to  refer  to  the  documen¬ 
tation  of  other  system  modules.  This  will  fee  necessary  or  desir¬ 
able  in  steps  k,  9,  10,  12,  and  13. 

Each  document  describing  a  system  model  will  he  organized  in 
the  same  way.  Figure  III-2  is  a  typical  table  of  contents.  Stan¬ 
dard  forms  have  been  provided  to  aid  in  modeling  which  will  fee 
included  in  Section  III  of  the  documents.  Examples  of  these  forms 
are  shown  in  Sections  2-0  and  3-0  below. 

Strict  adherence  to  these  documentation  standards  will  result 
in  a  maintainable  analysis  tool  with  a  long  useful  life. 
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Figure  III-l.  Development  of  Bjrete*  Module* 
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I. 

SYSTEM  CESCRIPTON 

II. 

OVERVIEW  OF  THE  SAINT  MODEL 

III. 

MODEL  DESCRIPTION  FORMS 

1- 0  Entities 

2- 0  Resources 

3- 0  Variables 

4- 0  Monitors 

5- 0  Task  Descriptions 

6- 0  Statistics 

7- 0  User  Functions 

8- 0  Moderator  Functions 

IV. 

USER  WRITTEN  SUBPROGRAMS 

1- 0  Index 

2- 0  Subprogram  Descriptions 

3- 0  Subprogram  Listings 

V. 

LISTING  OF  SAINT  NETWORK  DATA  INPUT 

VI. 

NON-SAINT  DATA  REQUIREMENTS 

1- 0  Data  Requirements 

2- 0  Data  Source  and  Description 

VII. 

OUTPUT  REPORTS 

1- 0  Output  Options 

2- 0  Sample  Output 

Figure  III-2.  Table  of  Contents  for  MOPADS  System  Module 
Documentat ion . 
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2-0  TEE  AH/TSQ-73  SYSTEM  MODULE 

2-1.  AH/TSQ-73  Operator  Tasks. 

Table  III-l  contains  the  operator  tasks  that  are  repre¬ 
sented  in  the  AH/TSQ-73  system  module.  An  important  part  of 
developing  MOPADS  operator  models  is  to  determine  which  operator 
tasks  are  required  to  be  represented.  Many  tasks  are  irrelevant  to 
the  air  battle  scenario.  These  include,  for  example,  tasks  related 
to  the  set-up,  take-down,  and  transportation  of  the  equipment, 
furthermore,  there  may  be  duplication  of  task  information  among  the 
task  descriptions  in  official  systos  documentation.  Also,  occa- 
sionaly  it  may  be  necessary  to  add  a  task  to  account  for  standard 
or  cannon  procedures  that  are  not  explicitly  discussed  in  the 
official  documentation. 

Development  of  the  task  lists  is  a  substantial  activity  that 
requires  the  MOPADS  modeler  to  became  familiar  with  all  of  the  tasks 
in  the  official  documentation  so  that  informed  decisions  can  be  made 
in  selecting  those  that  must  be  modeled.  Official  documentation  for 
the  AH/TSQ-73  (U.  S.  Army  Technical  Manual,  TM9-ll» 30-652-10-3), 

Change  6,  1981)  contains  flow  charts  for  the  operator  tasks.  An 
example  for  hooking  is  shown  in  Figure  III-3-  These  or  similar 
representations  must  he  obtained  from  the  pertinent  Army  documenta¬ 
tion  and  a  preliminary  task  list  determined.  This  activity  is  step  3 
of  figure  III-l.  Since  MOPADS  involves  models  of  combat  operations, 
the  operator  tasks  describing  set-up  and  routine  maintenance  of  equip¬ 
ment  can  usually  be  excluded  at  this  point  from  further  consideration. 

For  systems  that  have  more  than  one  operator,  it  may  be 
necessary  to  develop  task  lists  for  each  operator.  An  example  of 
this  case  will  be  seen  in  Section  3-0  for  the  IHAVK  system  module. 

For  the  AH/TSQ-73,  all  tasks  can  be  performed  from  each  console, 
although  it  is  customary  for  the  operators  to  perform  separate  tasks 
baaed  on  their  authority.  For  the  AH/TSQ-73,  this  task  split  is 
represented  structurally  in  the  models  rather  than  by  developing 
separate  task  lists  for  each  operator. 

An  important  objective  in  developing  the  task  list  is  to  select 
the  minimum  set  necessary  to  represent  the  operator  interaction  with 
the  ay a tern  to  the  required  detail.  Considerable  effort  is  expended 
in  expanding  each  operator  task  into  an  MSAIHT  representation.  There¬ 
fore,  the  task  list  must  be  examined  vith  s  critical  eye  to  ensure 
that  unnecessary  effort  is  not  expended.  As  an  example,  consider  the 
AH/TSQ-73.  The  usual  operator  configuration  is  to  have  a  Tactical 
Director  (TD)  who  has  authority  to  order  engagements  and  a  Tactical 
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Table  IH-1.  AI/TSQ-73  Operator  Teaks  Hepresented  In  MOPADS, 


IESCRIFTI9R 

Idl#  Tint  (Scat  the  lisplays) 
Caactl  Secondary  luifioiat 
Send  Ttmitait  Csmindt 
Cloar  Hold  Firs,  Effsctivs,  Status 
Forlorn  Hookiay  Frocsdurs 
Eator  II  aad  IFF  lata 
Interrogate  a  Target  or  Stctor 
Seed  Connaad  Message 
Assign  Meapons/lattalioas 
Receive  Connaads 
Cloar  ftlorts 

Rocoivo  Miscellaneous  Messages 


Director  Assistant  (TTSA)  who  does  not  have  such  authority.  The 
TDA  will  perform  tracking  and  identification  tasks,  and  the  TD 
will  order  and  monitor  engagements.  It  is  possible,  however,  to 
configurate  the  system  with*two  operators  that  each  have  engagement 
authority  (two  "TD's").  In  this  case,  each  operator  can  perform  »n 
tasks.  The  modeler  must  decide  which  configuration^ )  will  be 
Included  in  the  model  and  specify  task  lists  accordingly. 
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Step  2  In  Figure  1II-1  ia  to  "identify  C2  Data." 
Essentially,  this  step  involves  determining  how  operators  of  this 
equipment  communicate  with  superior,  -subordinate,  and  lateral 
units.  The  communications  occur  through  voice  and  data  link  messages. 

NOPADS  models  of  air  defense  systems  ( components)  mimic  this 
structure  by  conounicating  with  messages  sent  through  the  HOPAKS 
data  base.  It  is  necessary  for  the  MOPADS  modeler  to  explieity 
identify  all  communications  between  the  air  defense  system  being 
modeled  and  all  other  systems  already  modeled.  For  the  current 
implementation,  this  means  that  the  communication  between  the  group 
and  battalion  AH/TSQ-73  and  the  IHAVK  battery  must  be  identified. 

Once  again,  a  Judicious  elimination  of  messages  that  are  not  needed 
in  the  MOPADS1  context  will  greatly  reduce  later  work. 


The  messages  used  in  the  current  implementation  are 
shown  in  Table  III-2.  For  each  such  message,  the  sender,  receiver, 
message  characteristics,  and  message  contents  must  be  specified. 

A  form  has  been  developed  to  facilitate  specification  and  documen¬ 
tation  of  this  data.  An  example  is  shewn  in  Figure  ni-b. 


2-3.  AH/TSQ-73  Operator  Goals . 

Once  all  of  the  messages  and  tasks  for  the  operator 
have  been  determined,  initial  development  of  the  task  sequencing 
procedures  forvthe  operators  can  begin.  The  goals  for  the 
AH/TSQ-73  operators  have  been  shown  already  in  Table  II-3. 

The  particular  parameters  used  for  each  goal  priority 
function  are  specified  in  Goodin  A  Polito  (1983b). 

i 

2-h .  iiH/TSQ-73  Operator  Task  Models. 

A  SAIHT  task  node  modal  analogous  to  Figure  11-2  has 
b^en  developed  for  each  of  the  operator  tasks  shown  in  Table  III-l. 
This  procedure  involves  defining  the  "entities"  that  will  flew 
through  the  networks.  In  this  case .the  entities  are  operators. 

Rxh  entity  has  a  list  of  characteristics  called  attributes  that 
identify  it.  Each  of  the  operators  is  defined  on  a  form  as  in 
Figure  III-5.  The  attributes  of  the  operators  have  been  defined. 
These  attributes  are  used  in  branching  decisions  to  determine 
w.jich  Task  Node  will  be  performed  next  andj  in  FORTRAN  programs 
v.  ,'tten  by  the  MOPADS  modeler  to  represent  the  operators’  actions. 
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Figure  III-3.  Example  AN/TSQ-T3  Operator  Task  Flov  Chart. 
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Table  III-2.  Messages  for  the  AH/TSQ-T3  and  IHAWK. 
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Command  Nniijit 


Mold  Fire 
Cease  Fire 
Cease  Engagement 

I 

Cover  |  On  track  already  assigned 

legate  Ripple  ' 

Eagate  New  Track  Assignment 

Cover  Mew  Track  Assignment 

Eagate  Ripple  Assignment 

lavestigate/Assign  Assignment 

Cancel  Alert 

Track  Assignment  Status 

Change  Targets 

Method  of  Fire 

Order  No  Kill 

Order  Break  Lock 


Request  for  lnforsation  Messages 
Request  Cancel  of  TCC  Alert 


Reporting  Status  Messages 

1 

FU  Out  of  Action 

2 

3 

4 

3 

FU  Expended  Mot  Missiles 

FU  Effecjive/Not  Effective 

FU  Engaging  Fop-up  Target 

Neu  ASO  Target 

A 

0 

1H1F1R  Lock  Status 

Raid  Size  Report 

Temporary  No  Kill 

Acknowledgement  Messages 


1 

Mill  Comply  , 

2 

Nave  Complied  J  Battalion  0-73  to  Croup 

Can't  Comply  * 

4 

Mill  Comply  1 

Can't  Comply  /  1MAUK  tc  Battalion  0-73 

A 

Acknowledge  ASO  Target 

7 

Accept  i*S0  Target 
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HOP AOS  HESSA6E  DESCRIPTION 


Llmai 


HCSSABE  BATA  LINK  ELEMENT 


Elanmt 

Inscription 

Value 

1 

Connumcation  Network, 

2 

1 -Voice  2-ATDL 

2 

Acknouledgenent  Required 

1 

1  -  Tes  2  -  No 

3 

Unused 

4 

ATBL  Code  (Unused) 

S 

e  Tine  Message  Sent 

A 

•  Nessage  Nunber 

7 

e  Sender  CRN 

— - 

• 

Sender  Operator  Type 

1 

P 

Sender  Systen  Module  Type 

2  or  3 

to 

Task  Node  Nunber  Sent  Fro* 

— 

•  Must  be  set  at  the  tine  the  nessage  is  sent 

VAB1AILE  MESSAGE  FORHAT 

Elenewt 

BescriPtion 

1 

#  Words  ■  2 

2 

Which  Fire  Section  *  0  Either 

■  1  A 
«  2  B 

3 

_ 

Track  Colwn  Humber 

|  NESSAGE  SUBTYPE  DESCRIPTION  1 

Cover  nev  target  command.  Obtain  a  HIFIB  lock  on  a  nev 
target  but  do  not  fire. 


Nanai  Jack  Walker  Sytttn  Modulai  Q-73 

Bata  i  8/3/83  Project?  MOPADS 


Fron 

To 

Fron 

To 

GRPU5) 

BH(20) 

GRPU5) 

HAWK133) 

BH(15) 

HAWK( 33) 

Figure  III-4.  Example  Message  Sent  From  the  AN/TSQ-T3. 


MESSAGE  IB  ELEMENT 
Description 


Xacaivar  CBN 
Operator  Type 
Functional  Typo 
Massage  Subtype 
Massage  Priority 


*»S*  1  of  1 

1  Mat 


1  or  3 
1 
6 


<A 

a  'Si' 

& 

fljS 

k"'. 
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When  operator  characteristics  are  specified,  the  task  net¬ 
works  like  Figure  XI-2  are  expanded  to  describe  each  Task  Node. 
Figures  III-6,  7»  8*  and  9  are  examples.  On  these  forms  are 
specified  the  skill  and  skill  weight  requirements  (see  Table  II-l) , 
the  task  related  variable  data  (see  Table  11-2),  and  the  mean, 
standard  deviation  and  distribution  type  of  the  nominal  per¬ 
formance  time.  Any  resource  requirements  are  also  specified. 

The  MOPADS  operator  task  number  is  also  given,  so  a  cross- 
reference  is  possible  between  SAINT  task  nodes  and  operator  tasks. 
Given  a  task  node  number,  it  is  possible  to  find  the  operator  task 
that  contains  it  by  looking  at  the  forms  in  Figures  III-6  to  9*  Con¬ 
versely,  all  of  the  task  nodes  that  make  up  an  operator  task  model 
can  be  found  in  the  forms  shown  in  Figure  II-2. 

Speculation  and  verification  of  all  of  the  data  in 
Figures  III-5  through  III-9  completes  steps  7  to  10  in  Figure 
XIX-1.  This  leaves  step  11  which  involves  entering  data  inter¬ 
actively  into  the  MOPADS  data  base  to  support  the  system  module. 
SAINT  task  models  have  been  developed  for  each  operator  task,  and 
nominal  task  performance  times  and  skill  requirements  have  been 
determined  for  each  task  node. 

3-0  THE  IHAWK  SYSTIM  MODULE 


IHAWK  Operator  Tasks, 


The  IHAWK  operator  tasks  that  are  represented  in 
MOPADS  are  shown  in  Table  III-3.  A  separate  task  list  has  been 
prepared  for  each  IHAWK  operator,  because,  in  contrast  to  the 
AN/TSQ-73tthe  various  operators  perform  substantially  different 
functions.  By  far,  the  most  complex  activities  are  performed  by  the 
Tactical  Control  Officer  (TCO).  All  communications  to  other  air 
defense  components  are  represented  as  passing  to  and  from  the  TCO. 


The  other  operators  perform  relatively  straightforward  tasks. 
In  other  words,  the  task  sequencing  for  these  operators  is 
relatively  simple.  Their  activities  are  primarily  rule-based. 


The  process  of  developing  the  IHAWK  task  lists  was  analogous 
to  that  for  the  AN/TSQ-73.  It  was  somewhat  more  difficult  to 
develop  the  lists  and  network  models,  however,  because  the  Army 
documentation  (U.  S.  Army  Technical  Manual,  TM9-1^30-1526-12-1, 
June  30,  1979)  does  not  contain  task  flow  charts  analogous  to 
Figure  III-3.  The  activities  are  described  in  text  that  reeded  to 
be  examined  and  put  into  network  form. 
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Figure  III-7.  Exaaple  SAINT  Teak  Deecripfcioo  for  AN/TSQ-73.  (Node  *7) 
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Table  I I I- 3-  IfiAWK  Operator  Tasks  Represented  in  MOPADS . 

Bescriptioa 


MO  TASKS 

A8G  Standby,  Uait  for  Actios 
Select  Rev  Target  at  CUTBC 
Establish  Taryst  Priority 
Preenpt  Loner  Priority  Target 
TCC  Alert 

Nark  Target  as  Accepted  by  TCC 


FCO  A  FCO  I  TASKS 

FCO  Standby,  Uait  for  Actios 
Track  Target 

Obtain  Lock  on  Target  Manual]* 

Put  Fire  Section  out  of  Action 

Estinate  Raid  Size 

Select  Launcher 

Fire  Missiles 

Evaluate  Target  Intercept 

Process  Change  Targets 

Put  Fire  Section  hack  in  Operation 


TCA  TASKS 

TCA  Standby,  Uait  for  Action 
Accept  CUTSC  Target  Fro*  ASO 
IFF  Challenge 

Nark  os  Reflection  Plotter  <Friend,  Hostile,  Uakaoun) 


TCO  TASKS 

TCO  Standby,  Uait  for  Action 
letect  IPAR  ASP  Target 
Manually  Assign  Targets 
IHIPIR  Tracking 

TC0-IH1PXR  Sons  not  Acquire  Lock 

Higher  Priority  Target  to  be  Assigned  to  Firing  Section 

Process  a  Hostile  Target 

Assigned  Target  Seternined  Friendly 

Process  Friend 

Evaluate  Uhether  More  Missiles  Are  To  Be  Fired 
Bive  ASO  Pernissioa  to  Cancel  Alert 
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Table  III-3.  (continued) 


TCO  MESSAGE  TASKS 

Accept  0-73  Target  (ENGAGE  MODE) 

Accept  0-73  Target  (COVER  MODE) 

Accept  Change  Targets  Connand 

Receive  "HOLD  FIRE"  Connand 

Receive  "CEASE  FIRE"  Connand  y 

Receive  "CEASE  EN6A8E"  Connand 

Issue  "PRIORITT,  PRIORITT"  CALL  TO  Q-73 

Receive  "ROGER  ENGAGE"  Connand 

Send  Cannot  Conply  Message  to  Q-73 


3-2.  IHAWK  Messages. 

The  messages  used  in  the  current  implementation  were 
shown  in  Table  III-2.  This  table  includes  IHAWK  messages.  M0PAD3 
uses  the  message  concept  to  represent  voice  communication  within  a 
component  as  veil  as  data  link  and  voice  between  units.  This  mech¬ 
anism  is,  then,  used  in  a  uniform  way  to  represent  all  direct  commu¬ 
nication  between  individuals  in  the  MOPADS  models.  Figure  III-IO  i3 
an  example  of  a  voice  message  specifying  the  method  of  fire  which  is 
sent  between  operators  of  an  IHAWK  unit.  This  particular  message  is 
sent  by  the  TCO  to  the  Fire  Control  Officer  (FCO)  to  specify  the 
method  of  fire  for  attacking  a  particular  track. 

In  all  other  ways,  specification  of  the  messages  for  the 
IHAWK  is  analogous  to  the  process  discussed  in  Section  III,  2-2. 

3-3.  IHAWK  Operator  Goals. 

The  IHAWK  operators*  goals  were  shown  in  Table  II-3. 
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HO* AM  AESSA8E  BESCRJPTIOM 


MESSAGE  II  ELEMENT 


F*S«  ief  1 


Hifttni 


ImrieUu 

Receiver  CIA 
Operator  Typo 
Functional  Typo 
Xtiujt  Subtypo 
Message  Priority  . 


Kiln 

6  or  7 
1 
1U 


HESSA6E  IATA  LIMA  ELENEAT 


LLtatui 

i 


Inscription 
Connuniration  Network 
1 -Voice  2-ATBL 

Acknowledgement  Required 
1  -  Tot  2  •  No 

Unused 

ATDL  Code  (Unueed) 

Tine  Message  Sent 
Message  Nunber 
Sender  CRN 

Sender  Operator  Type 
Sender  Systen  Module  Type 
Task  Node  Nunber  Sent  Fro* 


XlLil 

1 


3 

k 


•  fluat  be  set  at  the  tine  the  nessage  is  sent 


VARIABLE  HESSA6E  FORMAT 


Qfnt.nl 

1 

2 
3 


Biim-gUia 

#  Words  ■  2 
Track  Column  Number 
Method  of  Fire  ■  1  Shoot-Look-Shoot 
■  2  Ripple  Fire 


HE5SASE  SUBTYPE  DESCRIPTION 

Method  of  Fire  Command.  Shoot-Look-Shoot  means  shoot  one 
then  evaluate  before  shooting  another.  Ripple  means  shoot  two 
[missiles. 


Nanet 

Bates 


Jack  Walker 

3A/83 


Systen  Modules  IHAWK 
Projects  MOPADS 


Pron 


TCO<27) 


To 


FCO 


Fron 


To 


Figure  III-10.  Example  IHAWK  Message. 
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3-J*.  IHAWK  Operator  Task  Models. 

Task  models  for  the  IHAWK  have  been  developed  in  the 
same  way  as  those  for  the  AH/TSQ-73.  Figure  III-ll  is  the  operator 
definition  for  the  TCA.  Each  of  the  operators,  tasks,  and  task 
nodes  has  been  specified  in  the  same  way  as  for  the  AH/TSQ-73. 

All  of  the  careful  data  collection  and  model  develop- 
ment  information  for  the  AH/TSQ-73  and  IHAWK  system  modules  have 
been  delivered  to  the  Army  in  four  volumes  (Goodin  A  Polito  (l98.Ta,b 
Goodin  t  Walker,  1983a,b). 


U-0  AIR  SGEHARIOS 

In  addition  to  representing  the  air  defense  system, ,M0PAD6 
must  have  a  model  of  the  air  battle  that  the  air  defense  system 
fights.  The  MOPADS  software  has  facilities  to  represent  the 
salient  features  of  the  air  battle  environment. 

The  data  required  for  the  air  scenario  representation  are 
the  following. 


1.  The  coordinate  syatem  reference  point. 

2.  The  locations  of  all  air  defense  units  and  protected 
sites  (critical  assets). 

3.  The  assignments  of  critical  assets  to  the  fire  units 
who  are  to  protect  them. 

j  It.  The  characteristics  of  each  radar  or  observer  that 
|  j  acquires  information  about  aircraft. 

5«  The  characteristics  and  flight  paths  of  all  aircraft. 


I  MOPADS  assumes  a  flat  earth  and  uses  rectangular  co¬ 

ordinates.  The  coordinates,  (x,  y,  *),  of  all  points  in  the  sys¬ 
tem  are  given  with  respect  to  a  user  specified  reference  point. 
This  point  may  be  specified  as  a  longitude  and  latitude  if  a 
specific  terrain  system  is  to  be  specified.  Once  the  reference 
point  Is  chosen,  all  other  coordinates  are  specified  with  refer¬ 
ence  to  it.  The  units  of  the  x  and  y  coordinate  are  nautical 
miles,  and  the  units  of  z  are  feet.  The  +x  axis  is  east,  the 
*y  axis  is  north,  and  +z  is  up. 
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Figure  II I -11.  Example  IHAWJC  Operator  Definition  Fora, 


V-2.  Locations  of  Air  Defense  Unite.  Critical  Assets ,  and 
Asset-Fire  Unit  Assignments. 


Figure  111-12  shows  an  example  layout  of  the  reference 
point  and  of  protected  assets.  With  this  basic  configuration,  a 
variety  of  air  defense  configurations  and  air  battles  can  be  simu¬ 
lated.  One  possible  configuration  is  shown  in  Figure  III-13.  This 
figure  shows  a  group  AH/TSQ-73  with  two  battalions.  The  battalions 
each  have  two  IHAWK  fire  units.  The  critical  assets  are  assigned 
to  fire  units  as  follows:  IHAWK  1  protects  site  1,  IHAWK  2  protects 
site  2,  and  IHAWKS  3  and  1»  both  protect  site  3*  The  circles  around 
the  units  represent  their  area  of  radar  coverage. 

Many  possible  configurations  could  be  arranged  to  protect  the 
three  critical  assets,  and  MOPALS  allows  the  MOPADS  user  to  specify 
the  location  and  assignments  of  the  air  defense  components. 

U-3.  Characteristics  of  Viewers. 

Each  air  defense  unit  may  "own"  one  or  more  "viewers." 
Viewers  are  usually  radars  (and  in  the  cvxrent  implementation,  they 
are  always  radars),  but  in  the  case  of  FEDEYE  or  VULCAK,  for 
example,  the  viewer  might  be  a  human  observer. 

Each  viewer  has  the  following  characteristics. 

1.  maximum  range 

2.  minimum  and  maximum  altitude 

3.  probability  of  detection 

1».  barriers  to  View 

5.  a  sector  of  interest 

The  characteristics  above  serve  to  restrict  a  viewer's  abil¬ 
ity  to  detect  aircraft.  The  maximum  range  and  altitude  restric¬ 
tions  are  self  explanatory.  The  probability  of  detection  is  the 
probability  that  the  viewer  v*ll  detect  an  aircraft  that  is  other¬ 
wise  in  its  field  of  view.  '.-CPAES  assumes  that  once  an  aircraft 
is  detected  it  remains  det'  .-ted  so  long  as  it  is  in  the  viewer's 
field  of  view. 

The  MOPADS  us*:  may  specify  barriers-to-vlew  that  block  out 
part  of  a  viewer's  ability  to  detect  aircraft.  The  barriers  approxi¬ 
mate  terrain  and  other  limitations  that  preclude  a  radar  or  observer 
from  seeing  everything  within  range.  Figure  IlI-lU  shows  how  barriers 
may  be  specified.  Two  types  of  barriers  may  be  specified:  line 
barriers  and  wedges. 


COORDINATE  AND  ASSET 
DATA 

.1 

/ 


▲  ▲ 


ASSETS 


J 


A 


REFERENCE  POINT 


Figure  III-12. Example  Critical  Asset  Configuration. 
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AIR  DEFENSE  CONFIGURATION 

1  GROUP (G)  2  Q-73's(Q)  A  IHAWKS(H) 


A  -  Critical  Asset 


Figure  III-13.  Example  Air  Defense  Configuration 
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PLAN  VIEW 


SIDE  VIEW 


# 


VIEWER 


Figure  III-ll*.  Viewers  and  Barriers-to-Viev. 


In  the  plan  view  of  Figure  III-lU,  two  line  barriers  are 
shown  to  the  east  and  southeast  of  the  viewer.  Everything 
farther  away  from  the  viewer  than  the  line  barrier  is  hidden  from 
view  if  it  is  in  the  shadow  of  the  barrier.  The  side  view  in 
Figure  III-14  demonstrates  this.  The  area  to  the  east  of  the 
barrier  and  below  the  shadow, is  hidden  from  the  viewer  (note,  the 
side  view  does  not  show  a  complete  detail  of  the  viewer  in  the  plan 
view). 

Line  barriers  may  be  positioned  anywhere  in  the  maximum  range 
of  the  viewer  and  the  end  points  may  have  different  altitudes. 
MOPADS  assumes  a  linear  variation  of  altitude  from  one  end  of  the 
barrier  to  the  other.  Using  multiple  line  barriers,  it  is  possible 
to  create  complex  viewing  areas  that  approximate  actual  radar 
viewing  patterns. 

Wedge  barriers  are  simply  pie  shaped  sections  in  which 
nothing  is  visible.  An  example  is  shown  in  Figure  III-lU  in  the 
plan  view  to  the  west  of  the  viewer.  The  user  specifies  the  start 
and  end  compass  headings  of  the  wedge. 


The  system  of  restricting  the  field  of  view  described  above 
is  not  a  perfect  representation  of  radar  vision  limits,  but  it 
permits  a  reasonable  approximation  for  modeling  purposes. 

The  IHAWK  permits  the  operators  to  specify  a  "sector  of 
interest"  which  is  a  pie  shaped  segment  of  its  viewing  area.  The 
IHAWK  computer  will  automatically  process  tracks  in  this  sector. 

The  sector  of  interest  has  no  effect  on  the  radar's  ability  to 
acquire  aircraft.  It  serves  only  to  delineate  a  high  interest  area 
to  the  computer.  MOPADS  has  a  facility  to  specify  a  sector  of  in¬ 
terest  for  each  viewer.  In  the  current  implementation,  the  sector 
of  interest  is  used  only  by  IHAWK. 


Characteristics  and  Flight  Paths  of  Aircraft. 


Aircraft  flight  paths  are  represented  as  sequential 
piece-wise  linear  segments.  The  start  and  end  coordinates  for  each 
segment  are  specified  along  with  the  speed  of  the  aircraft  ‘on  the 
segment.  The  x,  y,  and  2  velocities  are  computed  by  M0P4DS  and 
assumed  constant  along  the  segment.  The  MOPADS  modeler  may  specify 
as  many  segments  for  an  aircraft  as  desired,  and  as  many  aircraft 
as  desired  may  be  included  in  an  air  scenario.  Curvilinear  tracks 
may  be  approximated  as  sequences  of  linear  segments. 
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The  following  data  are  specified  for  each  aircraft: 


a.  Category 


b.  Identifying 

Rtaber 


A  track  may  be  "hostile," 
"friendly,"  or  "ether."  An 
"other"  track  Is  a  track  that 
curnot  be  classified  as  friendly'. 

The  user  nwy  specify  a  unique 
number  for  each  track. 


c.  Multiplicity 


The  masher  of  aircraft  in  the 
flight. 


d.  Aircraft  Type  Code  values  for  a  variety  of 

aircraft  types  are  provided. 

See  Table  III-h. 

(for  hostile  tracks  only)  -  This 
item  specifies  that  the  end  point 
of  a  flight  segment  is  an  air 
defense  unit  or  a  critical  asset 
that  the  air  defense  system  is 
attempting  to  protect. 

f.  Probability  of  (for  hostile  tracks  only)  -  If 
Destruction  the  end  of  the  segment  is  a  tar¬ 
get,  the  hostile  track  will 
attack  it.  This  item  is  the 
probability  that  the  site  is 
destroyed. 


e.  Whether  The 
Bid  Point  Of 
The  Segment 
Is  A  Target 


g.  Jamming  On  The  user  may  specify  that  a  hos- 

A  Segment  tile  track  is  employing  ECU  on  a 

segment.  This  information  is 
currently  not  used  by  MOPADS. 

It  is  provided  for  future 
enhancements. 
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Table  III-L.  Aircraft  Type  Codea. 


TARGET  TYPE  COOES 


COOE  NO. 

MANE 

COUNTRY 

MISSION 

1 

F4C 

USA 

2 

Ft  99 

USA 

I 

T33 

USA 

4 

OTHER  JET 

S 

VIA 

USA 

A 

t!4A 

USA 

7 

OTHER  PROP 

1 

91A 

USA 

f 

0H2J 

USA 

19 

OTHER  HELICOPTER 

11 

TANR 

12 

JEEP 

11 

TROOP 

* 

14 

APC 

IS 

TRUCK 

1* 

ZERO 

17 

HALFTRACK 

11 

F14 

USA 

tt 

FIS 

USA 

24 

FI4 

USA 

21 

F19 

USA 

22 

NI021 

USSR 

21 

NI823 

USSR 

24 

HIS2S 

•SSR 

2S 

SOLBIERCFOOT) 

ARY 

24 

HI9-27 

NSSR 

27 

StM7 

USSR 

29 

01AN9  Ji-S 

PRC 

Ground  Attack 

29 

R-2330 

FRANCE 

Rilitary  surveillance 

39 

HI RASE  3E 

FRANCE 

Fifhtrr 

11 

RIRASE  FI 

FRANCE 

Fighter 

12 

HIRASf  2904 

FRANCE 

Fifhtrr 

13 

RIRASE  4994 

FEANCE 

Fafhttr 

14 

RIRASE  4 

FRANCE 

Bonber 

IS 

RIRASE  3 

FRANCE 

Srauad  Support 

34 

RIRASE  SO 

FRANCE 

Fifhtrr 

37 

AN. 444 

MEAT  BRITAIN 

Rilitary  Transport 

39 

49S 

SREAT  BRITAIN 

Baabrr 

39 

NS74S 

SREAT  BRITAIN 

Rilitary  Transport 

49 

RS.7S9 

SREAT  BRITAIN 

Military  Traaapert 

41 

P.1999 

SREAT  BRITAIN 

Srauad  Attack 

IH-28 


Table  IIx-U.  (continued) 


42 

IAI202 

ISRAEL 

Military  Transport 

43 

MIRAGE  3C 

ISRAEL 

FigEstar 

44 

Kf irC2 

ISRAEL 

Fighter 

43 

6.222 

ITALY 

Military  Transport 

4A 

F1045 

ITALY 

latarceptor 

47 

MB.326K 

ITALY 

Strika 

48 

S.N.1019E 

ITALY 

Military  STOL 

4f 

F-1 

JAPAN 

Fightar 

50 

C.207A 

SPAIN 

Military  Transport 

31 

SF-3A 

SPAIN 

Fightar 

52 

HA-220 

SPAIN 

6round  Attack 

S3 

33X9 

SUEBEN 

Ground  Attack 

34 

JA37 

SUEDEN 

Fightar 

53 

J-1 

YUGOSLAVIA 

Strika 

3* 

Light  (a. g. blinking) 

57 

Bigit  (digit 

ea  a  display) 

31 

WIG— 1 7 

USSR 

The  organization  of  scenario  information  in  the  data  base  is 
shown  in  Figure  III-15 «  A  directory  is  created  called 
CRITICAL- ASSET-COT  FIGURATION  which  contains  the  specification  of  the 
coordinate  reference  point  and  the  location  of  all  critical  assets. 
This  information  is  contained  in  an  entry  COORDINATE-AHD- ASSET-DATA. 
Then  one  or  more  air  scenarios  (which  consist  of  aircraft  tracks) 
can  be  specified.  Each  air  scenario  contains  records  for  hostile, 
friendly,  and  other  tracks.  Thus,  for  a  single  configuration,  the 
MOPADS  modeler  can  create  a  menu  of  air  scenarios  that  attack  it 
(see  Figure  III-16) .  The  MOPADS  user  then  selects  from  this  menu, 
the  scenario  that  he  desires  to  simulate. 

Similarly,  more  than  one  CRITICAL-ASSET-CONFIGURATIOT  can  be 
created  in  the  data  base,  so  the  user  also  has  a  menu  of  such  con¬ 
figurations  to  choose  from.  When  a  simulation  is  designed,  the 
MOPADS  user  will  select  the  CRITICAL-ASSET-CONFIGURATION  and  the 
air  scenario  within  the  asset  configuration  that  he  desires  to 
simulate. 


U-5.  The  Control  System  Module. 

Every  MOPADS  simulation  will  automatically  contain  a 
system  module  that  does  not  represent  an  air  defense  unit.  This 
syston  module,  called  the  Control  8ystea  Module,  is  a  SAINT  model 
that  drives  the  air  scenario.  This  small  SAINT  model  initiates 
the  tracks  at  the  proper  time  and  simulates  their  flight  paths  to 
their  termination  points.  It  also  performs  statistics  collection 
and  information  management  on  all  track  data. 

The  control  system  module  also  ends  the  simulation  at  the 
time  specified  by  the  user.  The  module  consists  of  six  SAINT  task 
nodes  and  appropriate  FORTRAN  support  programs. 


wv\ 


Figur*  III-15*  Data  But  Organlrat? on  of  Air  Scenario  Information. 
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IV.  MOPADS  PROGRAM  IMPLEMENTATION 


1-0  MSJLDfT 

The  SAUfT  simulation  language  needed  to  be  modified  to  accent 
modate  the  MOPADS  requirement  for  "run-time  configurable"  air 
defense  systems.  In  other  vords,  it  must  be  possible  for  the  MOPADS 
user  to  specify  the  number  of  air  defense  units  to  be  simulated  and 
their  hierarchical  structure.  As  has  been  discussed,  the  logical 
issues  related  to  this  requirement  were  resolved  by  modeling  the 
intercommunication  among  components  as  messages  which  are  sent 
through  the  MOPADS  data  base.  At  the  computer  programming  level, 
however,  several  iasuea  still  needed  to  he  addressed. 

Since  the  MOPADS  modeler  cannot  know  in  advance  how  many 
copies  of,  say,  the  IHAHK  system  module  may  be  required  by  a  MOPADS 
user,  a  software  scheme  is  needed  to  replicate  the  system  modules 
an  arbitrary  number  of  tines.  SAIHT  task  nodes  are  numbered  (e.g. , 
1,  2,  3. ..)»  so  that  merely  duplicating  the  task  networks  would 
result  in  duplicate  node  numbers  which  are  unacceptable  to  the 
SAUTT  processor.  The  most  straight  forward  approach  to  this  pro¬ 
blem  is  to  develop  a  preprocessor  that  would  renumber  the  nodes  as 
the  network  duplicates  are  created.  On  the  surface,  this  appears 
to  be  an  acceptable  solution,  but  it  has  several  drawbacks: 

a.  Large  amounts  of  computer  memory  are  used  for  network 
storage  Replicating  essentially  identical  information  will  require 
large  computing  resources  to  run  MOPADS  models. 

b.  Technical  problems  result  in  matching  data  base  informa¬ 
tion  (much  of  which  is  keyed  to  individual  nodes)  to  the  (now  un¬ 
predictable)  node  number  of  replicated  networks. 

c.  Complex  cross-indexing  schemes  would  have  to  be 
developed  for  the  FORTRAI  insert  programs  that  are  an  integral  part 
of  each  system  module  so  that  it  would  bo  possible  to  know  which 
copy  was  being  processed  at  any  given  time. 

A.  Problems  (b)  and  (c)  above  are  compounded  when  more  than 
one  system  module  type  are  included  in  the  network. 

Using  the  approach  Just  described  would  have  required  a  complex 
programming  activity,  complex  indexing  designs  for  the  data  base, 
and  complex  programming  in  the  FORT  RAH  inserts.  Also,  it  would 
have  heavily  taxed  the  computing  resources. 
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An  alternative  ticheme  Is  to  modify  SAUfT  to  "share"  a  single 
network  representation  among  Multiple  realizations  of  "copies"  of 
the  network  (Folito  i  Walker  (1902)).  This  saves  substantial  com¬ 
puting  resources  and  allows  the  same  node  nrabers  to  be  used  for 
each  copy.  This  approach  has  been  Implemented  and*  in  fact,  the 
node  numbers  for  each  system  module  may  be  selected  independently 
of  the  node  numbers  of  all  other  system  modules.  The  programming 
to  perform  this  task  was,  of  course,  complex,  but  this  task  will 
\*v  performed  only  one  time,  and  it  greatly  simplified  the  design 
tad  programming  of  virtually  all  other  software  modules.  In  parti¬ 
cular,  the  development  of  air  defense  system  modules  is  made  much 
simplier  because:  . 

a.  node  numbers  may  be  selected  freely  without  knowledge 
of  node  manners  used  in  other  system  modules, 

b.  FORTRAH  insert  programs  do  not  have  to  cross  index 
node  numbers  to  determine  the  copy,  and 

c.  complex  cross-indexing  of  data  base  information  is 
not  required. 

This  scheme  represents  the  multiple  copies  of  system  modules  in  an 
elegant  manner  that  simplifies  model  development  and  substantially 
reduces  requirements  for  computing  resources. 

2-0  MOPADS  DATA  BASE 

The  MOPADS  software  must  maintain  a  great  deal  of  information 
about  a  variety  of  subjects: 

a.  data  which  describes  the  Air  Scenario  to  he  simulated, 

data  which  describes  the  tactical  scenario  which  in¬ 
cludes  location  and  characteristics  of  air  defense 
units,  the  command  and  control  system,  and  the  co¬ 
ordinate  reference  system, 

data  which  describes  the  characteristics  of  the  ope 
tors  of  air  defense  systems  and  the  environment  in 
which  they  function, 

data  which  describes  the  dynamic  relationships  of 
operator  tasks,  and 

e.  data  which  represents  statistics  collected  during 
simulat ions . 

All  of  this  information  must  be  maintained  in  an  easily  accessed 
and  edited  form,  and  it  must  be  addressed  in  a  way  that  permits 
multiple  data  aets  to  co-exist  without  confusion. 


b. 


c. 


d. 
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The  sost  effective  way  to  accomplish  this  is  with  a  unified 
data  management  system  or  a  data  base.  The  Data  Base  Control 
System  (DBCS)  module  of  the  MOFADS  software  performs  this  function. 

The  DBCS  is  a  non -traditional  data  base  manager.  However,  the 
organization  of  the  MOPADS  data  base  file  most  nearly  resembles  a 
hierarchical  data  base.  It  is  non-traditional  in  the  sense  that 
rapid  access  of  datum  elements  is  needed  during  MOPADS  simulation*. 
The  DBCS  utilizes  a  data  address  that  is  passed  into  and  out  the 
DBCS  which  permits  rapid  access  of  required  data.  The  addr  pre¬ 
cludes  most  hierarchical  searches  in  the  data  base  file  tn  locate 
data;  thus,  it  eliminates  many  dish  accesses.  Further.ore,  the 
DBCS  dynamically  retains  the  most  frequently  accessed  data  (not 
merely  the  most  recently  accessed)  in  main  memory,  so  disk  reads 
are  minimized.  These  features  make  the  DBCS  a  reasonably  fast  tool 
for  storage  and  retrieval  of  data. 

The  DBCS  is  a  collection  of  subprograms  which  any  application 
program  may  use  to  create  and  manipulate  a  data  base  file.  The  DBCS 
has  no  main  program,  so  it  has  no  stand-alone  capability.  It  was 
designed  to  provide  rapid  access  to  data  for  the  MOPADS  Bystem.  The 
DBCS  can  be  used  in  settings  other  than  MOPADS,  because  it  has  no 
built  in  structure  that  is  unique  to  MOPADS.  It  does  not,  however, 
have  many  traditional  data  base  features  because  of  its  specialized 
target  environment.  It  also  imposses  a  somewhat  greater  burden  on 
application  programs  than  other  similar  data  base  systems.  The 
DBCS  requires  the  application  program  to  remember  data  base  address 
information  which  is  used  by  the  DBCS  to  implement  fast  data  access. 

The  DBCS  provides  capabilities  to  perform  the  following  func¬ 
tions  on  data  base  files: 

1.  Open/ Close  DB  Files 

2.  Add/Delete/Rename  Directories 

3.  Add/Delete/Extend/Shorten  Data  Lists 

b.  Re ad /Write  Data  Lists 

5.  Set/Change  the  Data  Base  Protection  Mtde 

6.  Search  Directories  for  Particular  Data  Lists  or 
Directories. 

7.  Set/Access/Change  Labels  of  Data  Lists  and  Data 
List  Elements 

8.  Read/Write  External  Format  Data  Files  for 
Portability  of  Data  Base  Files 

9.  Set/Access  Various  DBCS  Options 

10.  Print  Contents  of  Data  Lists  and  Directories. 


In  order  to  reduce  the  number  of  disk  accesses,  the  DBCS 
computes  an  access  frequency  for  each  record,  and  then  keeps  the 
aost  frequently  accessed  records  in  core.  Since  patterns  of  record 
accessing  may  change  over  the  life  of  a  data  base,  an  exponentially 
smoothed  access  frequency  (SAF)  is  calculated  and  used  as  the  basis 
for  core  residence  decisions. 

Every  record  in  main  memory  (whether  it  has  been  resident  for 
seme  time  or  has  Just  been  read)  has  a  SAF  value  which  is  approxi¬ 
mately  comparable.  In  other  words,  it  represents  the  smoothed  access 
frequency  of  the  record  based  upon  nearly  the  same  criteria.  The 
DBCS  uses  these  values  to  determine  which  records  will  have  a 
tendency  to  be  retained  in  main  memory. 

A  set  of  data  base  application  programs  ( DBAP)  have  been 
written  to  implement  the  particular  data  base  used  by  MO PADS.  As 
mentioned  earlier,  DBCS  is  generic  and  has  no  structural  elements 
that  reflect  the  details  of  the  contents  of  the  MOPADS  data  base. 

The  DBAP,  however,  is  specialized  to  MOPADS  and  utilizes  the  DBCS 
to  manipulate  and  manage  the  data.  The  DBAP  provides  many  high  level 
data  base  access  functions  for  the  other  MOPADS  software  modules.  A 
schematic  of  the  software  structure  is  shown  in  Figure  IV-1.  In 
particular,  DBAP  programs  are  provided  for  the  Human  Factors  Modera¬ 
tor  Functions  to  access  operator  characteristics,  so  the  moderator 
functions  do  not  need  to  "know"  structural  information  of  how  MOPADS 
stores  data. 


USER 

INTERFACE 


OPERATOR 

SOFTWARE 
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Figure  IV-1.  DBCS  and  MOPADS. 


Examples  of  JV3  programs  are: 

1.  Create  a  MOPADS  data  base  on  a  nev  data  base  file. 

2.  Copy  portions  of  one  MOPADS  data  base  to  another. 

3.  Store/retrieve  elements  of  an  operator's  state  rector. 

l>.  Generate  MOPADS  error  messages  related  to  the  data  base. 

5.  Locate  all  air  defense  components  in  a  specified 
simulation  data  set. 

The  DECS  is  documented  in  Polito  (I9?3d).  The  DBAP  is 
documented  in  Polito  (!9S3e). 


3-0  THE  MOPADS  USER  INTERFACE 

3-1 .  Organization  of  the  MOPADS  User  Interface. 

The  MOPADS  user  Interface  has  five  subprocesses  which 
are  shown  schematically  in  Figure  IV-2.  Each  of  the  subprocesses 
provides  facilities  for  using  and  modifying  the  MOPADS  data  base. 


Suborocttiei: 

1  -  Create  Simulation  Data  Set 
l  -  Set  Up  Simulation  hm  Data 

3  -  Playback  Statlatlcs 

4  -  Create/Edit  Air  Scenario 

5  •  Create/Edit  Reference  System  Nodule 

Figure  TV-2.  Structure  cf  the  MOPADS  User  Interface. 
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Thre*  of  the  subprocesses  ere  for  use  primarily  hy  the  MOPADS 
user.  These  are  the  first  three:  Create  Simulation  Data  Set, 

Set  Up  Simulation  Run  Data,  and  Examine  Statistics.  The  remaining 
tvo  subprocesses,  Create/Edlt  Air  Scenario  and  Create/Edit  Reference 
System  Module,  are  primarily  for  the  use  of  the  MOPADS  modeler.  The 
functions  of  the  subprocesses  are: 

1.  Create  Simulation  -  This  aubprocess  allows  the  MOPADS 
Data  Set  user  to  specify  a  command  and  con- 

trol  configuration  with  indivi¬ 
dually  edited  copies  of  reference 
air  defense  system  modules. 

nils  subprocess  allows  the  MOPADS 
user  to  specify  data  for  a  MOPADS 
simulation.  The  user  specifies  a 
simulation  data  set  (previously 
constructed  with  subprocess  one 
above),  selects  the  air  scenario 
which  will  be  used,  and  assigns 
critical  assets  to  air  defense 
units  tc  be  defended. 

3.  Examine  Statistics  “  This  subprocess  allows  the  user  . 

to  review  and  selectively  print 
outputs  from  a  MOPADS  simulation. 

This  subprocess  provides  facili¬ 
ties  for  the  MOPADS  modeler  to 
create  new  air  scenarios  for  the 
MOPADS  user  to  simulate. 

This  subprocess  provides  facili¬ 
ties  for  the  MOPADS  modeler  to 
create  new  system  modules  for  the 
use  of  MOPADS  users.  This  process 
allovs  the  menu  of  available  air 
defense  system  modules  to  be 
expanded. 

Each  subprocess  is  an  interactive,  command-driven  processor. 


3-2.  Create  Simulation  Data  Set. 

Using  this  subprocess,  the  MOPADS  user  can  create  an  air 
defense  configuration  that;  may  be  simulated.  Figure  IV-3  shows  a 
schematic  of  the  data  base  operations  performed  in  this  subprocess. 


5.  Create/Edit  Reference  - 
System  Module 


4.  Create/Edit 
Air  Scenario 


2.  Set  Up  Simulation 
Run  Data 
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CHANGE  DELETE  INSERT,  QUIT  REMOVE 


Data  Base  Functions  of  the  "Create  Simulation  Data 
Set"  Subprocess. 
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The  menu  of  reference  system  modules  is  created  by  MOPADS 
modelers  using  xhe  Oreate/Edit  Reference  System  Module  process. 

The  result  is  a  set  of  complete  system  specifications  for  an 
AM/TSQ-73,  IHAWK,  etc.  The  reference  system  module  contains  de¬ 
fault  values  for  all  human  factors  and  system  parameters. 

When  using  the  Create  Simulation  Data  Set,  the  user  issues 
commands  that  cause  copies  of  the  reference  system  module  to  be 
placed  in  the  command  and  control  structure  devised  by  the  user. 
Thus  more  than  one  IHAWK  or  AN/TSQ-73  may  be  represented  in  the 
command  and  control  structure.  Each  of  these  copies  is  called  a 
working  air  defense  system  module.  The  working  system  modules  can 
be  individually  edited  to  reflect  differences  in  human  factors  para¬ 
meters  or  system  options. 

The  commands  unique  to  this  subprocess  are  shown  below: 

ADD  -  Create  a  new  simulation  data  set 

CHANGE  -  Edit  the  parameters  of  a  working  system  module 

DELETE  -  Delete  an  entire  simulation  data  set  and  all 

of  its  working  system  modules 

INSERT  -  Copy  a  reference  system  module  to  a  specified 
position  in  the  simulation  data  set 

REMOVE  -  Delete  a  specified  working  system  module  and  all 
of  its  subordinate  units 

QUIT  -  Leave  this  subprocess  of  the  user  interface 

Multiple  simulation  data  sets  can  be  created  and  stored 
simultaneously  in  the  MOPADS  data  base.  This  provides  a  capability 
to  create  a  menu  of  air  defense  configurations  that  can  be  simulated. 

3-3.  Set  Up  Simulation  Run  Data. 

With  this  subprocess,  the  user  completes  the  informa¬ 
tion  needed  to  perform  a  simulation.  Figure  IV-L  shows  the  data 
basic  operations.  An  entry  called  a  Tactical  Scenario  is  created 
that  belongs  to  a  particular  Simulation  Dato.  Set.  The  user 
selects  a  particular  critical  asset  configuration  and  air  scenario 
for  that  asset  configuration.  Furthermore,  ht  assigns  critical 
assets  to  fire  units  for  defense  and  specifies  certain  technical 
parameters  such  as  the  start  and  end  times  of  the  simulation.  Once 
this  information  is  stored  in  the  data  base,  it  is  necessary  only 
to  specify  the  simulation  data  set  and  the  tactic.il  scenario 
identifiers  to  MOPADS  in  order  to  perform  a  simulation. 
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Base  Functions  of  the  '’Set  Up  Simulation  Run  Data"  Subprocess 


The  coacands  unique  to  this  tubproeaas  «r«: 

ADD  -  Create  a  Tactical  Scenario  entry 

DELETE  -  Delete  a  Tactical  Scenario  entry 

EDIT  -  Set/revise  parameters  specified  in  the 
Tactical  Scenario  entry 

USE  -  Select  a  Simulation  Data  Set 

QUIT  -  Leave  this  subprocess 

More  than  one  Tactical  Scenario  entry  any  exist  in  one  Simu¬ 
lation  Date  Set.  Also,  the  statistics  produced  by  a  simulation 
are  stored  in  the  Tactical  Scenario  entry,  so  the  output  of  a 
simulation  is  always  stored  with  the  data  specification  that  pro¬ 
duced  it. 


3— it.  Examine  Statistics. 


This  subprocess  is  used  by  MO PADS  users  to  preview  and 
print  the  results  of  MO  PADS  simulations.  MSAIHT  writes  row  statis¬ 
tical  data  to  the  data  base  after  each  simulation  run.  It  la 
physically  stored  in  entries  of  the  Tactical  Scenarios.  This  sub¬ 
process  has  commands  that  permit  the  user  to  selectively  print  sta¬ 
tistics.  For  example,  it  is  possible  to  print  task  node  statistics 
for  a  particular  IHAWK  or  for  all  IHAWKs.  Similarly,  the  user  can 
print  all  operator  statistics  for  one  Q-T3  or  operator  statistics 
for  one  type  (e.g. ,  TD)  for  all  Q-73's. 

The  commands  unique  to  this  subproceas  are: 

DISPLAY 


PRINT 

SHOW 


USE 


-  Print  the  labels  of  all  Operators  and  all 
Working  System  Modules. 

-  Print  statistics. 

-  Print  the  Current  Simulation  Data  Set  Number, 
Tactical  Scenario  Number,  and  Run  Number. 

-  Change  the  Current  Simulation  Data  Set, 
Tactical  Scenario,  and/or  Run  Number. 
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3-5.  Create/Edlt  Air  Scenario. 

This  »ub  process  ir,  used  by  the  MOPAPS  modeler  to  create 
new  air  scenarios  for  the  M0PAL3  user.  Figure  III-15  is  a  schematic 
of  the  org&ai ration  of  the  dr.tu  base  information  for  Air  Scenario 
data.  A  Critical  Asset  Conf iguratioo  entry  contains  the  basic  data 
such  as  the  coordinate  reference  point  and  the  locations  of  all 
critical  assets.  Then  one  xr  acre  air  scenarios  can  be  created  with 
reference  to  this  coordinate  and  asst  system.  Each  air  scenario 
■ay  contain  tracks  classified  as  hosti'.i,  friendly,  and  other. 

Ccoands  unique  to  this  subprocess  are: 

ADD-AIR  -  Creates  a  new  air  scenario  entry  with  tracks 

ADD-ASSETS-  Creates  a  new  critical  asset  configuration  entry 

DELETE  -  Deletes  a  single  air  scenario  or  an  entire 
Critical  Asset  Configuration  entry 

GET  -  Copies  an  air  scenario  or  an  entire  Critical 

Asset  Configuration  from  a  reference  data  base 
to  the  working  data  base. 

RESAME  -  Renames  an  air  scenario  or  Critical  Asset 
Configuration 

SAVE  -  Copies  an  air  scenario  or  an  entire  Critical 

Asset  Configuration  from  the  working  data  base 
to  a  refei ence  data  base. 

The  user  interface  contains  provisions  to  maintain  reference 
type  information  such  as  scenario  data  in  a  reference  data  base  so 
that  it  is  not  subject  to  accidental  loss.  It  can  be  copied  into 
working  data  base  files  as  needed.  The  GET  and  SAVE  commands  per¬ 
form  this  function.  Use  of  this  subprocess  is  described  in 
Polito  (1983a). 

3-6.  Create /Edit  Reference  System  Module. 

This  subprocess  is  used  by  the  MOPADS  modeler  to  enter 
data  for  new  models  of  air  defense  systems  into  the  data  base. 

Figure  IV-5  shovt.  ohe  organization  of  the  reference  system  module 
information  ir.  the  data  base.  Vfoen  a  new  system  module  is  being 
created,  a r  .  all  of  the  data  have  been  prepared,  then  this  sub¬ 
process  's  used  to  enter  default  human  factors  and  system  option 
parameters  for  the  module.  This  effectively  increases  the  menu  of 
system  modules  available  to  the  MOPADS  user  for  performing 
simulations. 


CJEATE/EDIT  REFERENCE  AIR  DEFENSE  SYSTEN  NODULE 


REFERENCE-ASSN 

6P  AHrrsa-73 

AN/TSQ-73 

I  HAWK 

ETC. 

COTWDSj 

ADD  CHANCE  DELETE  6ET  QUIT  RENAME  SAVE  USE 


Figure  IV-5.  Data  Base  Organization  for  the  "Create/Edit 
Reference  System  Module”  Subprocess. 
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1b*  eniindi  unique  to  this  eubprceese  ere: 

ADD  -  Create  *  new  reference  air  defense  eyetan  nodule 

CHAHGB  -  Edit  the  parameters  of  a  reference  systm  nodule 

DELETE  -  Delete  a  reference  syjten  nodule 

GET  -  Copy  a  reference  systen  nodule  fron  a  reference 

data  base  to  the  working  data  base 

RECLAME  -  Rename  a  reference  systen  module 

SAVE  -  Copy  a  reference  systen  module  from  the  working 
data  base  to  a  reference  data  base 

USE  -  Specify  a  particular  reference  systen  module 

as  "current" 

QUIT  -  Leave  the  subprocess 
Use  of  this  subprocess  is  described  in  Polito  (1983b). 

3-7.  Basic  Data  Base  Commands. 

In  addition  to  the  commands  discussed  for  each  subpro¬ 
cess  ,  there  are  several  basic  commands  that  can  be  entered  from  any 
subprocess.  Those  commands  provide  lov  level  editing  or  data  base 
handling  services  for  the  user.  The  basic  data  base  commands  are 
discussed  below. 

CLOSE  -  The  CLOSE  command  will  close  either  the  working 
or  reference  data  hase.  It  can  be  used  to 
switch  to  a  new  data  base  file. 

CURRENT  -  The  CURR3LT  command  will  display  the  label,  ID 

or  both  of  the  current  directory  and/or  data  list 
on  either  data  base. 

DEPOSIT  -  DEPOSIT  is  a  low  level  editing  command  that  allows 
any  element  of  the  current  data  list  to  be 
changed.  DEPOSIT  interactively  requests  element 
numbers  and  new  values. 

DIRECTORY  -  DIRECTORY  shows  the  contents  (all  owned  direc¬ 
tories  and/or  data  lists)  of  the  current  direc¬ 
tory  on  either  data  base.  It  shows  the  labels, 
ID's,  and  directory  positions  of  the  contents. 

This  information  is  useful  for  the  SELECT 
command. 
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XXAHXHE  -  mNZR  will  diaplay  seleTtad  c  cat  acta  of  the 
current  data  Hat  to  the  terminal  or  to  the 
NOPADS  non-lnteractire  output  file.  If  th«  latter 
la  selected,  the  data  Hat  label  and  other  infor¬ 
mation  vlll  also  be  printed. 

HELP  -  HELP  vlll  print  the  prompt a  and  opt ion  a  far  the 
prompte  for  the  specified  roaamnd. 

MQfU  -  MZHU  haa  no  prompt  a.  It  vlll  print  all  ccmaanda 
available  in  the  current  aubproceaa. 


OPES  -  OPBI  vlll  open  a  data  baae  file  a a  either  the 
working  or  reference  data  baae.  OPEH  vlll  not 
automatically  close  the  current  data  base.  CLOSE 
must  be  used  explicitly  before  OPEH 
base  files. 

% 

PLINK  -  PLUTK  will  change  the  current  direi 

owner  of  the  directory  which  vaa  current  when 
PL  INK  was  issued. 


SELECT  -  SELECT  changes  the  current  directory  or  data  list 
to  one  that  is  owr.ed  by  the  directory  that  is 
current  when  SELECT  is  issued.  The  desired  direc¬ 
tory  or  data  list  is  selected  by  specifying  one 
(and  only  one)  of  the  following:  1  -  its  directory 
position,  2  -  its  label,  or  3  -  its  ID.  This 
information  is  obtained  with  the  DIRECTORY  command. 

TERMINATE  -  TERMINATE  has  no  prompts  It  will  close* all  open 
data  bases  and  terminate  execution.  This  is  the 
normal  way  to  end  a  User  Interface  session. 

3-8.  Conversing  With  the  MOPADS  User  Interface.  I 

('  1 

The  User  Interface  is  primarily  a  command  driven  pro¬ 
cessor  that  waits  for  the  user  to  issue  instructions.  It  does, 
however,  have  aspects  of  menu  driven  systems  in  that  some  commands 
result  in  menus  being  presented  to  the  user.  Also,  the  command 
processor  (FFSP  described  in  Goodin  %  Polito  (1983a)  )permits  menu-like 
presentations  of  commands. 


The  regular  mode  for  entering  commands  is  shown  below. 


command, prompt l=responsel/prompt2*response2/. . . 
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The  commands  and  prcmpta  are  keywords  recognized  by  MOPADS.  The 
responses  are  particular  values  for  the  prompts.  For  example, 
consider  this: 

OPER  ,FHJ>MOPABS .  DBF/STATUS»OLD 

OPER  is  the  ccamand.  PILE  and  STATUS  are  prcmpta  recognised  by 
MOPADS  and  MOPADS .DBF  and  OLD  are  values  for  the  prompts. 

Certain  prcmpta  for  a  ccamand  say  have  default  values  that 
will  be  used  if  the  prompt  is  not  entered.  In  the  example  above, 
another  pronpt,  DB,  specifies  which  data  base  is  to  be  associated 
with  the  file.  Its  default  is  WORKING,  so  by  not  entering  it  on  the 
c remand  line,  WORKING  is  automatically  selected.  If  the  default 
value  is  not  desired,  then  the  prompt  Bust  be  explicitly  entered  on 
the  command  line. 

If  the  user  fails  to  enter  responses  to  all  required  prompts, 
MOPADS  will  interactively  prompt  for  than.  For  example, 

OPHI,  STATUS-OLD 

FILE [HO  DEFAULT!  »  MOPADS. DBF 


While  processing  the  OPEN  command,  MOPADS  found  that  the  required 
prompt,  FILE,  was  not  entered.  It  printed  "FILE [NO  DEFAULT]*",  to 
prompt  the  user  for  a  response.  If  the  last  non-blank  character  on 
a  conn  and  line  is  a  dash  (-),  MOPADS  will  interactively  prompt  for 
all  unentered  prompts,  even  those  with  defaults.  For  example, 

OPEN , STATUS*OLD  - 
DB  [WORKING!  *  REFERENCE 
FILE [NO  DEFAULT]  *  MOPADS. DBF 


The  dash  caused  "DB  [WORKING)  =  "  to  be  printed.  The  value  between 
the  brackets  is  the  default  for  the  prompt.  The  default  can  be 
selected  by  typing  "DEF"  as  the  response.  DEF  can  also  be  entered 
on  the  command  line;  e.g., 

OPEN , DB=DEF/STATUS=OLD/FILE=MOPADS . DBF 


The  above  demonstrates  that  the  prompt-response  groups  can  be 
entered  in  any  order. 
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Also,  •  co— nd  can  1m  cancelled  at  any  tlaa  jjr  typing  "CAIC" 
aa  a  raapwiia  or  a  prompt.  For  example, 

OPEN ,CANC 
OPEN ,FILE“CANC 


lot*  that  DEF  and  CAHC  are  essentially  reserved  vords.  The  user 
Interface  treats  commas,  Hanks,  and  equal  signs  as  interchange¬ 
able  separators.  Also,  araltiple  separators  are  treated  aa  a  single 
separator.  This  means  that  the  enemas  in  the  previous  examples 
could  be  replaced  by  any  combination  of  one  or  more  blanks  and 
cosmas.  The  same  is  true  of  the  equal  signs,  but  their  use  is 
recommended  to  make  the  command  lines  easy  to  read.  The  slashes  are 
required  separators  between  prompt-response  groups,  but  they  can 
be  preceded  or  followed  by  blanks  or  commas. 

A  response  may  include  separators  (i.e.,  commas,  blanks, 
equal  signs,  end  slashes)  if  it  is  enclosed  in  quote  marks  ("). 

For  example,  on  some  computers  file  names  contain  embedded  blanks, 
e.g.. 


OPES  FILE" "MO PADS  DBF" 


Without  the  quote  marks  above,  MOPADS  will  consider  MOPADS  EOF  as 
two  responses  when  only  one  is  desired.  (NOTE:  A  single  prompt 
may  have  more  than  one  response  if  the  programmer  specified  it  that 
way.  In  such  a  case,  each  response  would  be  separated  by  a  blank 
or  comma.  In  the  case  above,  however,  where  a  single  response  is 
required,  the  quote  marks  must  be  used  to  embed  the  blank  in  the 
response.) 

Any  response  may  be  enclosed  in  quotes,  although  there  is  no 
advantage  in  doing  so  unless  a  separator  is  to  be  embedded.  Blank 
responses  can  be  entered  with  "  "  where  at  least  one  blank  appears 

between  the  quotes. 

A  generalization  of  entering  only  some  of  the  prompts  is  to 
enter  only  the  command  name: 


OPEN 

DB  [WORKING] =DEF 

FILE [NO  DEFAULT ] =MOPADS . DBF 

STATUS [OLD] =DEF 
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Tht  User  Interface  will  prompt  for  all  responses.  Ibis  method  can 
be  selected  if  the  user  does  not  remember  the  proopt s. 

For  commands  which  the  user  issues  frequently,  a  concise  mode 
can  be  selected  by  preceding  the  cooaand  with  "C-".  In  this  case, 
the  proopt*  part  of  the  syntax  a ay  be  oaitted.  For  example, 

C-OPZH  DEF/MDPAD6 .DBF 

Responses  oust  be  entered  in  the  sane  order  as  they  are  prompted  in 
the  ccmmaad-name-only  fora.  Ho  response  aay  be  shipped,  except  that 
if  all  remaining  responses  have  defaults  and  the  default  a  are 
desired,  then  the  command  line  may  be  terminated  ( e.g. ,  the  STATUS 
response  was  omitted  above  since  OLD  was  desired).  The  dash  works 
in  the  concise  mode  in  the  same  way  as  in  other  modes. 

The  following  rules  will  formalize  the  previous  discussion  cf 
how  syntax  is  processed  by  FFSP. 

1.  The  command- name-only  fora  of  a  command  may  be  used  at 
any  time  by  typing  only  the  command  name. 

2.  Blank  responses  and  responses  containing  separators  may 
be  entered  by  enclosing  them  in  quotes.  To  enter  a 
blank  response, type  "  "  (including  the  quotes).  At 
least  one  blank  must  be  entered  between  the  quote  marks. 

3.  A  command  may  be  cancelled  at  any  time  by  typing  CANC 
for  any  prompt  or  response.  You  can  not  abbreviate  CANC. 

k.  The  usef  may  elect  to  use  the  default  value(s)  by 

typing  DEF  for  any  response  in  a  response  list  up  to  one 
field  past  the  last  response  in  the  list. 

5.  Slashes  (/)  must  be  used  to  separate  one  prompt-response 
group  from  another.  Blanks  or  comas  may  be  used  to 
separate  all  other  fields.  The  equal  sign  should  be 
used  to  separate  prompts  from  their  responses;  however, 
it  is  not  required. 

6.  Command  and  prompt  names  may  be  abbreviated  to  any  non- 
ambiguous  string  of  characters.  For  example,  if  there 
are  two  commands,  DESIGN  and  DESCRIBE,  they  can  be 
abbreviated  DESI  and  DESC  respectively.  The  commands 
may  be  abbreviated  in  longer  forms.  For  example,  the 
user  may  enter  DESC,  DESCR,  DESCRI,  DESCRIB,  or  DESCRIBE 
for  the  command  DESCRIBE. 

7.  If  a  command  line  in  regular  or  concise  mode  is  ended 
with  more  than  one  dash,  the  last  dash  will  signify  to 
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the  system  to  prompt  the  user  for  all  the  unentered 
response*.  Other  dashes  will  then  be  considered  as 
part  of  a  response. 


8.  Any  multiple  combination  of  enemas  and  blanks  is  treated 
as  a  single  separator.  For  example, 

KAMI  -  BILL  WOLF  and  NAME  «  BILL  ,  VOLF 

are  equivalent  (here  the  response  is  a  list  of  two 
character  strings). 

9.  If  the  user  enters  an  incorrect  response  or  mi  sues  the 
syntax,  FFSP  will  explain  the  error  and  prompt  inter¬ 
actively  for  all  remaining  responses. 

10.  Concise  mode  is  signified  by  preceding  the  command  name 
with  "C-"  (without  the  quotes). 

The  user  interface  is  designed  to  be  easy  to  use  and  to 
support  novice,  intermediate,  and  expert  users.  The  HELP  and  MENU 
commands  and  the  cammand-name-only  form  provide  extensive  help  for 
novice  users.  Conversely,  the  concise  mode  allows  frequently  used 
commands  to  be  entered  without  excessive  typing.  Furthermore,  the 
ability  to  use  abbreviations  for  commands  and  prompts  permits 
experienced  users  to  reduce  typing  effort  in  even  the  regular  mode. 
Examples  of  User  Interface  commands  and  terminal  sessions  are  given 
in  Polito  ( 1983a, b) . 

L-0  UTILITIES  AND  SUPPORTING  SOFTWARE 

l-l .  MOPADS  Utilities. 

A  set  of  utility  programs  have  been  developed  to  support 
the  rest  of  the  MOPADS  software  (Polito  &  Goodin,  1983).  These 
programs  provide  standard  services  in  loading  and  copying  arrays, 
managing  auxiliary  array  storage,  opening  files,  and  encoding/ 
decoding  character  strings  in  a  machine  independent  scheme.  These 
low  level  services  are  used  by  virtually  all  other  MOPADS  software 
modules. 

k-2.  FFSP  and  FFIN2. 


Two  software  modules  are  used  to  provide  interactive 
terminal  functions  for  the  user  interface.  FFIN2(Polito,  1983c)  is  a 
set  of  format  free  input  programs  that  predate  MOPADS.  FFIN2  pro¬ 
vides  extensive  error  checking  for  input  entered  from  the  terminal, 
and  it  protects  the  user  from  abnormal  termination  due  to  mistyping. 
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V.  GUIDE  TO  MOPADS  DOCUMENT  AT  ION 


1-0  HOPATS  VOLUME  1 

This  report  comprises  MOPADS  Volume  1.1.  It  is  the  final 
report  for  the  project  and  provides  an  introduction  to  the 
concepts  used  in  MOPADS.  Subsequent  MOPADS  volumes  contain  user 
and  refemece  material  for  the  MOPADS  modeler. 

1-1 .  Volume  1  Contents. 

Title  and  Description 

MOPADS  Final  Report 

This  report  describes,  in  a 
non-technical  manner,  the 
MOPADS  modeling  system  and 
the  MOPADS  software.  The 
methodology  is  described 
and  a  simplified  description 
of  the  software  implementation 
is  given. 


2-0  MOPADS  VOLUME  2 

There  are  no  documents  in  MOPADS  Volume  2. 


Volume 

1.1 


V-l 


3-0  MOPADS  VOLUME  3 


MOPADS  Volume  3  contains  reports  that  provide  user  documenta¬ 
tion.  They  are  mandatory  reading  for  individuals  who  will  design, 
perform,  and  analyze  simulations  using  MOPADS.  These  documents 
provide  sufficient  information  for  a  MOPADS  user  to  exercise  the 
models  that  exist  in  MOPADS. 

3-1.  Volume  3  Contents. 


Volume  Title  and  Description 

3.1  User  Guide  for  the  AN/TSQ-73 

System  Module 

This  document  describes  the  AN/ 
TSQ-73  model.  It  provides  infor¬ 
mation  required  by  a  MOPADS  user 
such  as  a)  the  number  and  type 
of  operators,  b)  the  default 
human  factors  and  system  para¬ 
meters,  c)  the  operator  goals,  d) 
other  data  requirements,  and  3)  a 
discussion  of  the  implementation. 

3.2  User  Guide  for  the  IRAWK  System 

Module 

This  document  is  analogous  to 
Volume  3.1  except  for  the  IHAWK 
system. 

3.3  Performing  MOPADS  Simulations 

This  document  contains  user  in¬ 
structions  on  hov  to  use  the 
MOPADS  User  Interface  to  set  up 
and  perform  MOPADS  simulations. 

It  also  contains  information  on 
analyzing  the  outputs  from  simu¬ 
lation.  It's  intended  audience 
is  the  MOPADS  user. 

U-0  MOPADS  VOLUME  h 

MOPADS  Volume  U  is  a  collection  of  documents  for  the  MOPADS 
modeler  vho  will  design  and  develop  MOPADS  models  of  new  air  defense 
systems  and  integrate  them  vith  the  rest  of  the  MOPADS  system. 
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4-1.  Volume  4  Contents. 


Volume 


Title  a".  1  Description 


4.1 


MOPADS  Architecture  Manual 


4.2 


4.3 


4.4 


4.5 


This  document  contains  a  descrip¬ 
tion  of  the  modeling  framework 
and  the  software  structure  of 
MOPADS.  It  is  prerequisite 
reading  for  the  MOPADS  modeler. 

FORTRAN  Style  and  Documentation 
Requirements 

All  new  FORTRAN  code  written  for 
the  MOPADS  project  has  been 
written  following  the  standards 
specified  in  this  document.  It 
is  recommended  that  all  follow-on 
developments  also  use  this 
standard. 

Documentation  Requirements  and 
Development  Guidelines  for  MOPADS 
Air  Defense  System  Modules 

This  document  describes  the  docu¬ 
mentation  procedures  that  have  been 
used  to  develop  the  AN/TSQ-73  and 
IHAWK  system  modules.  It  is 
recommended  that  the  procedures  in 
this  report  be  used  for  all  follow- 
on  development s  also. 

Development  Methodology  for  MOPADS 
Air  Defense 

This  document  describes  a  step-by- 
step  methodology  for  developing 
air  defense  system  modules.  It  has 
been  used  for  the  AN/TSQ-73  and 
IHAWK  system  modules.  It  is 
recommended  that  these  procedures 
be  used  in  all  follow-on 
development  s . 

MSAINT  User’s  Guide:  Changes  and 
Additions  to  the  SAINT  User's 
Manual 
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Tni.s  document  describes  changes 
made  to  the  SAINT  simulation 
language  to  support  MOPADS.  It 
is  written  as  a  supplement  and 
addendum  to  existing  SAINT  docu¬ 
mentation.  Therefore,  the  reader 
must  be  foliar  with  the  SAINT 
language. 

U.6  Creating  Reference  Air  Defense 

System  Modules 

/ 

This  document  describes  the  pro¬ 
cedures  for  using  the  KOPALS  user 
interface  to  enter  data  for  a  new 
air  defense  system  module  into  the 
MOPADS  data  base. 

U.7  Creating  MOPADS  Air  Scenarios 

This  document  describes  the  pro¬ 
cedures  for  using  the  MOPADS  user 
interface  to  enter  new  air  scenario 
and  critical  asset  configuration 
data  into  the  MOPADS  data  base. 


5-0  MOPADS  VOLUME  5 

MOPADS  Volume  5  is  a  collection  of  reference  documents  that 
describe  the  methodology  and  software  modules  of  MOPADS.  They  are 
intended  as  reference  reports  of  primary  interest  to  the  MOPADS 
modeler,  although  MOPADS  users  may  find  some  of  them  interesting. 


5-1.  Volume  5  Contents. 


Volume 


Title  and  Description 


5.1  A  Summary  of  the  Literature  on 

Quantitative  Human  Performance 
Models 
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This  document  contains  summary 
sheets  of  the  literature  search 
conducted  of  the  human  perfor¬ 
mance  literature  for  MOPADS.  It 
is  comprised  primarily  of  raw 
data  used  for  the  data  base 
described  in  Volume  5*2. 

A  Data  Base  for  Quantitative 
Human  Performance  Modeling 


V-l* 


5.2 


This  document  describes  a  compu¬ 
terized  system  for  organizing  the 
information  described  in  Volume 
5.1  and  the  use  of  the  computer 
program  to  identify  relevant 
literature  to  develop  the  MOPADS 
skills  taxonomy. 

Selected  Operator  Functions  and 
Tasks  for  the  AH/TSQ-73  Missile 
Minder 

This  working  document  contains  raw 
task  flow  chart  data  extracted  from 
AN/TSQ-73  system  documentation. 

Selected  Operator  Functions  and 
Tasks  for  the  Improved  HAWK 
Missile  Battery 

This  document  is  analogous  to 
Volume  5.3  except  for  the  IHAWK. 

The  Underlying  Person  Model  Behind 
HOMO  (Human  Operator  Model) 

This  document  describes  the  skill 
taxonomy  for  modeling  air  defense 
operators . 

HOMO  Establishment  of  Performance 
Criteria  for  Non-Decision  Making 
Tasks 

This  docunent  describes  the 
moderator  function  approach 
developed  for  MOPADS,  and  the  way 
in  which  task  times  are  moderated 
by  breaking  tasks  down  into  com¬ 
ponent  skills. 

MOPADS  Task  Sequencing  Structure 

This  document  describes  the  metho¬ 
dology  used  for  operator  task 
sequencing.  Operators  are  repre¬ 
sented  in  MOPADS  as  goal  seekers. 
This  report  describes  the  proce¬ 
dures  used  to  model  the  goal 
seeking  behavior. 
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MOPADS  Documentation  Style  Manual 
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5.10 


5.11 


5.12 


5.13 


5.14 


5.15 


Thi«  repo>-t  describes  the  documen¬ 
tation  style  used  for  writing  and 
typing  MOr>ADG  reports. 

MOPADS  Utility  Programs 


This  report  documents  the  MOPADS 
software  uodrle  171IL  which  con¬ 
tains  general,  pregrro  utilities. 

Huisan  Factors  !toderator  Functions 

This  report  dccunents  the  MOPADS 
software  module  which  implements 
the  humor,  factors  moderator 
functions. 

MOPADS  Free-Forma*  Syntax  Pro¬ 
cessor  (MOPADS/FFSP) 

This  report  documents  the  MOPADS 
software  module  which  interprets 
the  MOPADS  U3er  interface  command 
syntax. 

MOPADS  User  Interface  (MOPADS/UI) 

This  report  documents  the  MOPADS 
software  module  that  implements 
the  user  interface. 

The  MOPADS  Data  Bass  Control 
System  (MOFADS/DBCS) 

This  report  documents  the  MOPADS 
software  module  that  manipulates 
the  MOPADS  data  base  file. 

MOPADS  Free-Format  Input 
Program  ( M0PADS/FFIN2 ) 

This  report  documents  the  MOPADS 
software  module  that  performs  low 
level  format  free  input  for  FFSP 
(3ee  Volume  5-U)  and  the  user 
interface. 

Documentation  Manual  for  the 
AN/TSQ-73  System  Module 
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This  report  contains  detailed  docu¬ 
mentation  of  the  AN/TSQ-73  system 
module.  Complete  SAINT  subnet-works 
for  each  operator  task  are  shown 
with  cross  references  between 
SAINT  task  node  numbers,  operator 
task  numbers,  and  references  to 
Army  documentation.  Also,  all 
SAINT  user  FORTRAN  inserts  are 
documented. 

Documentation  Manual  for  the  IHAWK 
System  Module 

This  document  is  analogous  to 
Volume  5.15  except  for  the  IHAWK 
system  module. 

5  The  MOPADS  Data  Base 

This  report  specifies  the  contents 
gnd  format  of  the  MOPADS  data  base 
file. 

5<1a  The  MOPADS  Data  Base  Application 

Programs  (MOPADS/DBAP) 

This  report  documents  the  MOPADS 
software  module  that  contains 
utilities  that  interact  with  the 
MOPADS  data  base  through  the  DBCS 
(Volume  5.13). 

5.19  Documentation  Manual  for  the  MOPADS 

Control  Module  ( MOPADS /CNTRL)  and 
The  MOPADS  Common  System  Module 
Module  Programs  (MOPADS/CSMP) . 

This  document  is  analogous  to 
Volumes  5.15  and  5.16  for  a  system 
module  called  the  Control  System 
Module.  This  module  is  not  an 
air  defense  system  module.  Rather 
it  is  a  special  SAINT  subnetwork 
which  manages  aircraft  tracks  and 
drives  the  software  that  updates 
track  position  and  ATDL  information. 
In  addition,  certain  programs  common 
to  all  system  modules  are  documented. 
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MOPADS  Terminology 


AIR  DEFENSE  SYSTEM 

A  component  of  Air  Defense  which  includes 
equipment  and  operator:;  and  for  which 
technical  and  tactical  training  arerequir'id. 
Examples  are  IBANK  and  the  AH/TSP-73. 

AIR  DEFENSE  SYSTEM 
MODULE  (ADSM) 

Models  of  operator  actions  and  equipment 
characteristics  for  Air  Defense  Systems  in . 
the  MOPADS  soft-ware.  These  models  are  pre¬ 
pared  with  the  SAIIJT  simulation  language. 

Air  Defense  System  Modules  include  the 

SAJI7T  model  and  all  data  needed  to  com¬ 
pletely  define  task  element  times,  task 
sequencing  requirements,  and  human  factors 
influences. 

AIR  SCENARIO 

A  spatial  and  temporal  record  of  aerial 
activities  and  characteristics  of  an  air 
defense  battle.  The  Air  Scenario  includes 
aircraft  tracks,  safe  corridors,  ECM,  and 
other  aircraft  end  airspace  data.  See 
also  Tactical  Scenario. 

BRANCHING 

ir 

A  term  used  in  the  SAJBT  simulation  lang¬ 
uage  -to  mean  the  process  by  which  TASK  nodes 
are  sequenced.  At  the  completion  of  the 
simulated  activity  at  a  TASK  node,  the 
Branching  from  that  node  determines  which 
TASK  nodes  will  be  simulated  next. 

DATA  BASE  CONTROL 
SYSTEM 

That  part  of  the  MOPADS  software  which 
performs  all  direct  communication  with  the 
MOPADS  Data  Base.  All  information  transfer 
to  and  from  the  data  base  is  performed  by 
invoking  the  subprograms  which  make  u>  the 
Data  Base  Control  System. 

DATA  SOURCE 
SPECIALIST 


A  specialist  in  obtaining  and  interpreting 
Army  documentation  and  other  data  needed  to 
prepare  Air  Defense  System  Modules. 


ENVIRONMENTAL 
STATE  VARIABLE 


An  element  of  an  Environmental  State 
Vector. 


ENVIRONMENTAL 

STATE  VECTOR 

An  array  of  values  representing  conditions 
or  characteristics  that  may  affect  more 
than  one  operator.  Elements  of  Environmen¬ 
tal  State  Vectors  may  change  dynamically 
during  a  MOPADS  simulation  to  represent 
changes  in  the  environment  conditions. 

"moderator  FUNCTION 

A  mathematical/logical  relationship  which 
alters  the  nominal  time  to  perform  an  opera¬ 
tor  activity  (usually  a  Task  Element).  The 
nominal  time  is  changed  to  represent  the 
operator's  capability  to  perform  the 
activity  based  on  the  Operator's  State 
Vector. 

MOPADS  DATA  BASE 

A  computerized  data  base  designed  specifi¬ 
cally  to  support  the  MOPADS  software.  The 
MOPADS  Data  Base  contains  Simulation  Data 
Set(s).  It  communicates  interactively  with 
MOPADS  Users  during  pre—  and  post -run  data 
specification  and  dynamically  with  the  SAINT 
software  during  simulation. 

MOPADS  MODELER 

An  analyst  who  will  develop  Air  Defense 
System  Modules  and  modify/ develop  the 

MOPADS  software  system. 

MOPADS  USER 

An  analyst  who  will  design  and  conduct  simu¬ 
lation  experiments  with  the  MOPADS  software. 

MSAIMT  The  variant  of  SAINT  used  iu  the  MOPADS 

(KQPADS/SAINT)  system.  The  standard  version  of  SAINT  has 

been  modified  for  MOPADS  to  permit  share¬ 
able  subnetworks  and  more  sophisticated 
interrupts.  The  terms  SAINT  and  MSAINT  are 
used  interchangeably  when  no  confusion  will 
result.  See  also,  SAINT. 


OPERATOR  STATE 
VARIABLE 


One  element  of  an 


ator  State  Vr ctor. 


OPERATOR  STATE 
VECTOR 

An  array  of  values  representing  th«  condi¬ 
tion  and  characteristics  of  an  operator  of 
an  Air  Defense  System.  Many  values  of  the 
Operator  State  Vector  will  change  dynamically 
during  the  course  of  :a  MOPADS  simulation  to 
represent  changes  in  operator  condition. 

OPERATOR  TASK  ■ 

.  i 

An  operator  activity  identified  during 
weapons  system  front-end  analyses. 

SAINT  j  1 

The  underlying  computer  simulation  language 
used  to  model  Air  Defense  Systems  in  Air 
Defense  System  Modules.  SAINT  is  an  acronym 
for  Systems  Analysis  of  Integrated  Networks 
of  Tasks.  It  is  a  well  documented  language 
designed  specifically  to  represent  human 
factors  aspects  of  man/machine  systems. 

See  also  MSAIHT. 

SIMULATION  DATA  SET  The  Tactical  Scenario  plus  all  required 

simulation  initialization  and  other  expert - 
t  mental  data  needed  to  perform  a  MOPADS 

simulation. 


SIMULATION  STATE  At  any  instant  in  time  of  a  MOPADS  Simula- 

i  tion  the  Simulation  State  is  the  set  of 

I  ,  values  of  all  variables  in  the  MOPADS  soft¬ 

ware  and  the  MOPADS  Data  Base. 


SYSTEM  MODULES  See  Air  Defense  System  Modules. 


The  Air  Scenario  plus  specification  of 
critical  assets  and  the  air  defense  con¬ 
figuration  (number,  type  and  location  of 
veapcns  and  the  command  and  control  system) . 


TACTICAL  SCENARIO 


TACTICAL  SCENARIO 
COMPONENT 

An  element  of  a  Tactical  Scenario,  e.g. , 
if  a  Tactical  Scenario  contains  several 
Q-T3’s,  each  one  ia  a  Tactical  Scenario 
Component. 

TASK 

See  Operator  Task. 

TASK  ELEMENTS 

Individual  operator  actions  vhich,  vhen 
grouped  appropriately,  make  up  operator 
tasks.  Tank  elements  are  usually  repre¬ 
sented  by  single  SAINT  TASK  nodes  in  Air 
Defense  System  Modules. 

TASK  NODE 

A  modeling  symbol  used  in  the  SAINT  simula¬ 
tion  language.  A  TASK  node  represents  an 
activity;  depending  upon  the  modeling  cir¬ 
cumstances,  a  TASK  node  may  represent  an 
individual  activity  such  as  a  Task  Element, 
or  it  may  represent  an  aggregated  activity 
such  as  an  entire  Operator  Task. 

TASK  SEQUENCING 
MODERATOR 

FUNCTION 

A  mathematical /logical  relationship  vhich 
selects  the  next  Operator  Task  vhich  an 
operator  vill  perform.  The  selection  is 
based  upon  operator  goal  seeking  character¬ 
istics. 

Additional  Terminology  and  Abbreviations 


BN 

Battalion 

Q-73 

AN/TSQ-73  * 

TD 

Tactical  Director 

TDA 

Tactical  Director  Assistant 

TD1,  TD2 

The  operator  of  a  Battalion  AN/TSQ-73 
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! >  INTRODUCTION 


1- 0  P JR POSE 

This  document  is  a  user  manual  for  the  AN/TSQ-73  system  module. 
It  contains  details  of  th*»  implementation  of  the  MOPABS  model  of  the 
AN/TSQ-73  system.  This  information  is  found  nowhere  else  in  the 
MOP ADS  documentation.  Actually,  two  system  modules  exist  for  the 
AN/TSQ-73:  one  for  Battalion  operators  and  one  for  Group  operators. 
Both  are  described  in  this  report. 

The  contents  of  the  operator  state  vectors,  environmental  state 
vectors,  and  task  data  are  given  in  this  report.  Section  II  contains 
a  brief  description  of  the  AN/TSQ-73  system.  Section  III  presents 
the  contents  of  the  operator  state  vectors.  The  environmental  state 
vector  is  described  in  Section  IV.  The  operator  tasks  and  task 
sequencing  assumptions  are  given  in  Section  V.  Finally,  Section  VI 
describes  assumptions  used  in  developing  the  module. 

2- 0  INTENDED  AUDIENCE 

MOPADS  users  and  MOPADS  modelers  should  read  this  report.  The 
language  and  level  of  detail  used  in  the  discussion  is  oriented  to 
the  MOPADS  user,  however.  Programming  and  implementation  details 
are  not  included  here.  This  information  is  discussed  in  detail  in 
MOPADS  volumes  four  and  five. 

3- 0  OTHER  READING 

The  reader  is  presumed  to  be  familiar  with  the  MOPADS  system. 
This  implies  that  he/she  should  have  read  the  final  report,  Polito 
&  Laughery  1983,  prior  to  reading  this  document.  In  addition,  the 
reader  should  be  familiar  with  the  main  MOPADS  user  manual,  Polito 
(1983a).  More  technical  data  on  the  AN/TSQ-73  system  module  is 
found  in  Goodin  St  Walker  1983. 
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II.  SYSTEM  DESCRIPTION 


The  AN/TSQ-73  ( Q— 73)  is  the  command  center  for  all  the  air 
defense  systems  in  MOPADS.  The  primary  mission  is  to  protect  vital 
assets  such  as  airfields,  and  ammunition  supply  centers  from  enemy 
air  attacks.  The  Q-73  performs  this  mission  by  controlling  various 
fire  units  so  that  the  mission  is  carried  out  effectively  and  as 
efficiently  as  possible.  The  Q-73  has  the  ability  to  detect,  iden¬ 
tify,  track  and  direct  engagements  against  aircraft  flying  at 
various  altitudes. 

MOPADS  can  represent  two  echelons  of  command  in  the  Q-73's. 

The  highest  level  is  the  Group  Q-73  which  may  control  one  or  more 
Battalion  Q-73's.  The  Battalion  Q-73  nay  have  severed  XHAWK  fire 
units  under  its  control.  The  Group  Q-73's  serve  as  checks  on  the 
actions  of  the  Battalion  Q-73's  so  that  two  Battalion  do  not  engage 
the  same  aircraft. 

During  an  air  scenario  the  Battalion  Q-73  will  work  with  its 
fire  units  in  detecting  and  identifying  aircraft.  The  Battalino 
may  assign  the  aircraft  to  different  fire  sections  depending  on 
which  one  is  the  most  capable  of  handling  the  engagement.  The 
Battalion  will  always  have  the  final  word  on  whether  or  not  to  fire 
at  a  target  it  assigned  to  a  fire  section. 

There  are  two  operators  manning  the  Group  and  Battalion  Q-73* 
The  MOPADS  Q-73  system  modules  represent  these  operators.  The 
operators  are  described  in  the  following  forms.  On  the  forms  the 
MOPADS  operator  type  is  shown  in  the  column  labeled  OPERATOR  NUMBER, 
and  the  MOPADS  label  for  each  operator  is  shown  in  parentheses  in 
the  column  labeled  OPERATOR  TITLE. 
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III. 


OPERATOR  DATA 


1-0  TACTICAL  DIRECTOR  (TD) 


1-1.  Human  Factors  Parameters. 

Table  III-l  shovs  the  default  values  for  the  human  factors 
parameters  of  the  Battalion  Tactical  Director  (TD).  This  data  is 
part  of  the  operator  state  vector  for  the  TD.  Discussions  of  these 
variables  are  contained  in  Polito  &  Litfghery  1983,  Laughery  1983, 

&  Polito  (1983b).  . 


The  last  elements  of  this  list,  X -SCREEN-CENTER,  Y-SCREEN- 
CEHTER,  and  SCBEE3I-RANGE,  are  set  when  the  system  module  is  copied 
into  a  command  and  control  configuration. 


Table  III-l.  ID  Human  Factors  Parameters, 


37.00000  CORE-TEMPERATURE 

1.000000  CIQ-VALUE 

O.OOOOOOOE+OO  TXME-0N-TASK 
C.OOOOOOOE+OO  DAYS-0F-DUTY 
1.000000  SEARCH-DIMENSIONS 

O.OOOOOOOE+OO  NUMBER-FIRE-UNITS 
100.0000  PERCENTAGE-RECOVERY 

8.000000  PREVIOUS-WORK 

16.00000  PREVIOUS-REST 

O.OOOOOOOE+OO  FLASH-INTENSITY 
O.OOOCOOOE+OO  TARGET-SPEED 
57.00000  TARGET-TYPE 

O.OOOOOOOE+OO  TARGET-SIZE 
6.000000  TARGET-COLOR 

360.0000  SEARCH-AREA 

O.OOOOOOOE+OO  BINOCULAR-USAGE 
O.OOOOOOOE+OO  SLANT-RANGE-TO-TARGET 
O.OOOOOOOE+OO  TARGET-TRAJECTORY 
1.000000  TARGET-BAKGRND-COHPLEXITY 

O.OOOOOOOE+OO  NUM-BACKGROUND-CHARACTERS 
O.OOOOOOOE+OO  MESSAGE-BACKLOG 
5.000000  SIGNALS-PER-MINUTE 

40.00000  HOURS-WORKED-PER-WEEK 

O.OOOOOOOE+OO  DAYS-WITHOUT-SLEEP 
O.OOOOCOOE+OO  DAYS-OF-NIGHT-DUTY 
1.000000  SIMULTANEOUS-TASKS 

1.000000  CONTRAST-RATIO 

8.000000  AVE-H0URS-3LEEP 

1.000000  OBJECTIVE-FUNCTION 

6.000000  GOALS-CONSIDERED 

1.000000  TARGET-BRIGHTNESS 

2.000000  NIGHTS 

1.000000  SKY-GROUND-RATIO 

O.OOOOOOOE+OO  AIRCRAFT-ALTITUDE 
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Table  III-l  (continued) 
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4.000000 

1  *fc>00000 

0.2Q80000E-01 
0.2080000E-01 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
1.000000 
1 .  oooooo 

O.OOOOOOOE+OO 
360.0000 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
5 .000000 
O.OOOOOOOE+OO 
800.0000 
0.5000000E-01 
0 . 5000000E-01 
0.5000000E-01 
1.330000 
1.000000 
1.000000 
10.00000 
1.000000 
20.00000 
0.1000000 
1.000000 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
1.000000 
20.00000 
240.0000 
20.00000 
-9999.000 
-9999.000 
-9999.000 


METEOROLOGICAL -RANGE 

THRESHOLD-CONTRAST 

TARGET-HEIGHT 

T  ARGET-UIDTH 

TARGET-DEPTH 

HORIZONTAL-RANGE 

NUM-OF-RESOLUTION-ELEM 

NUM-OF-SUSPECT-AREAS 

AIRCRAFT-SPEED 

FIELD-OF-VIEU 

OBSERVER-OFFSET 

UNUSED 

DISPLAY-TARGET-LOCATION 

TARGET-LOCATION 

DISPLAY-RESOLUTION 

DISPLAY-BACKGROUND-HEIGHT 

DISPLAY-BACKGROUND-UIDTH 

DISPLAY-BACKGROUND-DEPTH 

DISTANCE-TO-DISPLAY 

DISPLAY-HEIGHT 

DISPLAY-WIDTH 

TARGET-NOISE-LEVEL 

TARGET-DURATION 

EXPERIENCE 

SIGNAL-PROBABILITY 

REST-PERIODS 

TASK-ERROR-FACTOR 

TASK-ELEMENT-ERRQR-FACTOR 

DAYS-SINCE-PRACTICE 

SENSE-OF-DIRECTION 

SKIN-TEMPERATURE 

TIME-IN-TEMPERATURE 

PREVIOUS-SKIN-TEMPERATURE 

X-SCREEN-CENTER 

Y-SCREEN-CENTER 

SCREEN-RANGE 


> 

! 
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1-2.  Goals,  Goal  Priority  Functions,  and  Objective  Parameters. 

There  are  eight  goals  defined  for  the  AN/TSQ-73  operators. 
Figure  III-l  explains  the  goals  and  the  goal  states.  Not  all  oper¬ 
ators  have  all  goals.  The  TD  has  goals  1,  2,  3»  6,  7»  and  8. 

Goals  one  and  two  reflect  the  operator's  desires  to  protect 
himself  and  defend  the  critical  assets.  For  the  TD,  the  critical 
assets  that  he  is  trying  to  protect  are  those  assigned  to  his  fire 
units. 

Each  Track  is  evaluated  to  calculate  its  time  to  arrive  at  the 
AN/TSQ-73  location  and  at  each  of  the  protected  sites.  The  minimum 
of  these  times  is  the  track's  threat.  Thus,  the  most  threatening 
track  has  the  smallest  value  for  its  threat.  Goal  three  motivates 
the  TD  to  attack  enemy  aircraft  even  if  they  do  not  pose  an  imme¬ 
diate  high  threat. 
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Goals  four  and  five  cause  the  TEA  to  initiate  and  identify 
tracks.  Goal  six  vill  motivate  the  TD  to  prevent  more  than  one  of 
his  fire  units  from  simultaneously  engaging  the  same  track.  Goal 
seven  causes  the  operators  to  respond  to  communications  I'rom  within 
their  own  unit  and. from  other  units.  Goal  eight  will  cause  engage¬ 
ments  against  friendly  aircraft  to  he  terminated.  The  situation  can 
arise  if  a  friendly  track  appears  to  be  a  high  threat  befoi  e  it  can 
b»  identified. 

Goal  priority  functions  must  be  specified  for  the  goals  which 
specify  how  the  goal  priority  changes  with  differirg  values  of  the 
goal  states.  As  discussed  in  Polito  &  Laughery  1932  and  Polito 
(1983c),  thi3  is  done  by  specifying  two  points  on  the  goal  priority 
function  above  and  below  the  range  of  satisfaction.  This  data  for 
the  TD  is  shown  in  Figure  III-2. 

Table  XII-2  shows  how  this  data  appears  in  the  operator  state 
vector.  Each  goal  is  represented  by  15  values.  The  first  of 
which  is  the  goal  number.  If  this  number  is  negative 
then  the  operator  does  not  have  that  goal.  The  data  shown  in 
Figure  III-2  is  given  in  the  elements  LITTLE-M,  BIG-M,  and  elements 
GOAL-STATE-LOW-1  through  PRIORITY-HIGH-2.  The  values  of  LITTLE-A , 
LITTLE-B,  BIG-A,  and  BIG-B  are  calculated.  See  Polito  (1983a)  for 
warnings  on  changing  these  numbers.  Infinity  is  represented  in  the 
operator  state  vector  by  the  number  10^-0. 

Objective  function  parameters  for  the  TD  are  contained  in  his 
operator  state  vector.  Table  III-l.  The  objective  function  is  speci¬ 
fied  as  J'one"  which  means  that  the  TCO  selects  the  task  which  offers 
the  greatest  improvement  in  his  goad  state.  If  objective  function 
two  is  specified,  the  TCO  attempts  to  obtain  the  greatest  goal 
improvement  per  unit  time.  Finally,  the  TD  considers  all  of  his 
goals  when  selecting  his  next  task  (i.e.,  GOALS-CONSIDERED  is  six). 


Table  III-2.  TD  Goal  Priority  Function  Parameters. 


1,000000 
90.00000 
0. 1000000E+U 
0.9290031E-30 
15.93882 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
1.500000 
10.00000 
10.00000 
2.000000 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 


GOAL 

LITTLE-M 

BIG-M 

LITTLE-A 

LITTLE-B 

BIG-A 

BIG-B 

G0AL-STATE-L0U-1 
PRI0RITY-L0U-1 
GOAL -STATE- LOW-2 
PRIORITY-LOU-2 
GOAL-STATE-HIGH-1 
PRIORITY-HIGH-1 
GOAL- STATE-HIGH-2 
PRIORITY-HIGH-2 


Table  III-2  (continued) 


Hi 

kf : 


2.000000 

GOAL 

90.00000 

LITTLE-H 

0 • 1000000E+1 1 

BIG-M 

i  j 

0 . 8003029E-31 

LITTLE-A 

H 

16.47427 

LITTLE-B 

0 . 0000000E4  00 

BIG-A 

O.OOOOOOOE+OO 

BIG-B 

jyi 

1.500000 

GOAL-STATE-LOU-1 

9.500000 

PRIORITY-LOU-1 

10.00000 

GOAL-STATE-LOW-2 

1.800000 

PRI0RITY-L0U-2 

O.OOOOOOOE+OO 

GOAL-STATE-HIGH-1 

O.OOOOOOOE+OO 

PRIORITY-HIGH -1 

M 

O.OOOOOOOE+OO 

GOAL-STATE-HIGH-2 

O.OOOOOOOE+OO 

PRIORITY-HIGH-2 

3.000000 

GOAL 

-0.1000000E+11 

LiTTLE-M 

& 

O.OOOOOOOE+OO 

BIG-M 

O.OOOOOOOE+OO 

LITTLE-A 

O.OOOOOOOE+OO 

LITTLE-B 

2.000000 

BIG-A 

w 

0 . 7195524E-02 

BIG-B 

M 

O.OOOOOOOE+OO 

GOAL-STATE-LOU-1 

O.OOOOOOOE+OO 

PRIORITY-LOU-1 

O.OOOOOOOE+OO 

GOAL-STATE -LOU-2 

yy 

O.OOOOOOOE+OO 

PR I  OR J  TY- LOU-2 

1.000000 

GOAL -ST  ATE-hIGH-1 

2.000000 

PRIORITY-HIGH-1 

2.000000 

GOAL -ST  ATE-HIGH-2 

2.010000 

PRIORITY-HIGH-2 

O.OOOOOOOE+OO 

PRIORITY-LOU-1 

m 

o.oooocooe-;  oo 

GOAL-STATE-LOW-2 

Mi 

O.OOOOOOOE+OO 

PRIORITY-LOW-2 

O.OOOOOOOE+O} 

GOAL-STATE-HIGH-1 

m 

» 

O.OOOOOOOE+OO 

PRIORITY-HIGH-1 

O.OOOOOOOE+OO 

GOAL-STATE-HIGH-2 

fmm 

°6?S8oOOOE+00 

PRTnRTTY-HIGH-2 

GOAL 

-0.1000000E+11 

LITTLE-H 

O.OOOOOOOE+OO 

BIG-M 

IK. 

■ 

O.OOOOOOOE+OO 

LITTLE-A 

O.OOOOOOOE+OO 

LITTLE-B 

2.500000 

BIG-A 

»•  i 

0.1659562 

BIG-B 

fr 

c-: 

O.OOOOOOOE+OO 

GOAL-STATE-LOU-1 

O.OOOOOOOE+OO 

PRIORITY-LOU-1 

O.OOOOOOOE+OO 

GOAL-STATE-LOU-2 

O.OOOOOOOE+OO 

PRI0RITY-L0U-2 

f.3 

1.000000 

GOAL-STATE-HIGH-1 

? 

2.500000 

PRIORITY-HIGH-1 

r...* 

3.000000 

GOAL-STATE-HIGH-2 

3.000000 

PRIORITY-HIGH-2 

•*-  *, 

7.000000 

GOAL 

*■% 

O.OOOOOOOE+OO 

LITTLE-M 

O.OOOOOOOE+OO 

BIG-M 

1.000000 

LITTLE-A 

1.000000 

LITTLE-B 

ft* 

£1 

1.000000 

BIG-A 

1.000000 

BIG-B 

-1.000000 

GOAL-STATE-LOU-1 

1.000000 

PRIORITY-LOU-1 

»  . 

-2.000000 

GOAL-STATE-LOU-2 

2.000000 

PRI0RITY-L0U-2 

*vc 


Table  III- 2  (continued) 


1. 000000 
1.000000 
2.000000 
2.000000 
8.000000 
-0. 1000000E+11 
0.0000000E+00 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
9.000000 
0 . 1 6021 34E-02 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
1.000000 
9.000000 

?. 000000 
.010000 


GOAL-STATE-HIGH-1 

PRIORITY-HIGH-1 

GOAL-STATE-HIGH-2 

PRIORITY-HIGH-2 

GOAL 

LITTLE-M 

BIG-M 

LITTLE-A 

LITTLE-B 

BIG-A- 

BIG-B 

GOAL-STATE-LOU-1 

PRIORITY-LOU-1 

GOAL -ST  ATE -LOU- 2 

PRIORITY-LOU-2 

GOAL-STATE-HIGH-1 

PRIORITY-HIGH-1 

GOAL-STATE-HIGH-2 

PRIORITY-HIGH-2 


1-3.  Display  Data. 

Table  HI-3  is  the  display  data  for  the  TD.  The  first 
element  is  the  currently  hooked  item  if  one  exists.  The  other 
elements  are  explained  below. 

VECTORS  (0  -  no  vectors,  1  -  velocity  vectors  on,  2  -  Time 
to  go  vectors  on) 

SCREEN-ALPHA  (0  -  Off,  1  -  On) 

EKGAG1MI3T -MARKERS  (0  -  Off,  1  -  On) 

PAIRING-LINES  (0  -  Off,  1  -  On) 

MAP  (0  -  Off,  1  -  On) 

SCREEN-RANGE  (default  is  100  nautical  miles) 


Table  III-3-  TD  Display  Data. 


O.OOOOOOOE+OO 
1.000000 
O.OOOOOOOE+OO 
1.000000 
1.000000 
1.000000 
100.0000 
-9999.000 
-9999 . 000 
O.OOOOOOOE+OO 


HOOKED-ITEH 

VECTORS 

SCREEN-ALPHA 

ENGAGEMENT-MARKERS 

PAIRING-LINES 

MAP 

SCREEN-RANGE 

SCREEN-X 

SCREEN-Y 

UNUSED 
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The  coordinates  of  the  center  of  the  screen  are  not  specified 
unt  11  the  system  module  is  copied  into  a  command  and  control  con¬ 
figuration.  At  that  time,  the  user  may  specify  the  position  of  the 
center  of  the  TD's  viewing  area.  If  the  user  fails  to  specify  this 
data  (by  editing  the  operator  state  vector),  then  MOPADS  will  set 
it  equal  to  the  position  of  the  AN/TSQ-73. 

2-0  TACTICAL  DIRECTOR  ASSISTANT  (TDA) 

2-1.  Human  Factors  Parameters. 


V 

%• 


V* 


Table  III-U  contains  the  human  factors  parameters  for  the 
Tactical  Director  Assistant  (TDA).  The  comments  in  Section  1-1 
apply  equally  to  the  data  for  the  TDA. 

2-2.  Goals.  Goal  Priority  Functions,  ar.d  Objective  Parameters. 

The  TDA  has  goals  four,  five,  and  seven  from  Figure  III-l. 
Goals  four  and  five  causes  the  TDA  to  initiate  and  identify  tracks, 
and  goal  seven  causes  him  to  attend  to  communi?'"  Hns.  The  gqal 
priority  data  for  the  TDA  is  shown  in  Figure  1; ;  j.  Table  III-5 
shows  how  this  data  appears  in  the  operator  state  vector. 

Table  Ill-k.  TDA  Human  Factors  Parameters. 


37.00000 
1.000000 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
J .000000 
O.OOOOOOOE+OO 
100.0000 
8.000000 
16.00000 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
57.00000 
O.OOOOOOOE+OO 
6.000000 
360.0000 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
1.000000 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
5.000000 
40.00000 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
l. 000000 
1.000000 
8.000000 
1.000000 
3.000000 
1.000000 


CORE-TEMPERATURE 

CIO-VALUE 

TIME-ON-TASK 

DAYS-OF-DUTY 

SEARCH-DIMENSIONS 

NUMPER-FIRE-UNITS 

PERCENTAGE-RECOVERY 

PREVIOUS-WORK 

PREVIOUS-REST 

FLASH-INTENSITY 

TARGET-SPEED 

TARGET-TYPE 

TARGET-SIZE 

TARGET-COLOR 

SEARCH-AREA 

BINOCULAR-USAGE 

SLANT-RANGE-TO-TARGET 

TARGET-TRAJECTORY 

TARGET-BAKGRND-COMPLEXITY 

NUM-BACKGROUND-CHARACTERS 

MESSAGE-BACKLOG 

S I GNALS -PER -MINUTE 

HOURS- WORKED-PER-WEEK 

DAYS-UITHOUT -SLEEP 

DAYS-OF-NIGHT-DUTY 

SIMULTANEOUS-TASKS 

CONTRAST-RATIO 

AVE-HOURS-SLEEP 

OBJECTIVE-FUNCTION 

GOALS-CONSIDERED 

TARGET-BRIGHTNESS 
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Table  III-’*  (continued) 


2.000000 

NIGHTS 

1.000000 

SKY-GROUND-RATIO 

O.OOOOOOOE+OO 

AIRCRAFT-ALTITUDE 

4.000000 

METEOROLOGICAL-RANGE 

1.000000 

THRESHOLD-CONTRAST 

0.2080000E-01 

TARGET-HEIGHT 

0.2080000E-01 

TARGET-WIDTH 

O.OOOOOOOE+OO 

TARGET-DEPTH' 

O.OOOOOOOE+OO 

HORIZONTAL-RANGE 

1.000000 

NUM-OF-RESOLUTION-ELEM 

1.000000 

NUM-OF-SUSPECT-AREAS 

O.OOOOOOOE+OO 

AIRCRAFT-SPEED 

360.0000 

FIELD-OF-VIEU 

O.OOOOOOOE+OO 

OBSERVER-OFFSET 

O.OOOOOOOE+OO 

UNUSED 

5.0C0000 

DISPLAY-TARGET-LOCATION 

O.OOOOOOOE+OO 

TARGET-LOCATION 

800.0000 

DISPLAY-RESOLUTION 

0.5000000E-01 

DISPLAY-DACKGRGUND-HEIGHT 

0 . 5000000r-01 

DISPLAY-BACKGROUND-WIDTH 

0.5000000E-01 

DISPLAY-BACKGROUND- DEPTH 

1.330000 

DISTANCE-TO-DISPLAY 

1.000000 

DISPLAY-HEIGHT 

1.000000 

DISPLAY-WIDTH 

10.00000 

TARGET-NOISE-LEVEL 

1.000000 

TARGET-DURATION 

20.00000 

EXPERIENCE 

0.1000000 

SIGNAL-PROBABILITY 

1.000000 

REST-PERIODS 

O.OOOOOOOE+OO 

TASK-EPROR-FACTOR 

O.OOOOOOOE+OO 

TASK-ELEKENT-ERROR- FACTOR 

O.OOOOOOOE+OO 

DAYS-SINCE-PRACTICE 

1 .000000 

SENSE-OF-DIRECTION 

20.00000 

SKIN-TEMPERATURE 

240.0000 

TIME-IN-TEMPERATURE 

20.00000 

PREVIOUS-SKIN-TEMPERATURE 

-9999.000 

X-SCREEN-CENTER 

-9999.000 

Y-SCREEN-CENTER 

-9999.000 

SCREEN-RANGE 

Table  III-5.  TDA  Goal  Priority  Function  Parameters. 


4.000000 

GOAL 

-0. 1000000E+11 

LITTLE-M 

O.OOOOOOOE+OO 

BIG-M 

O.OOOOOOOE+OO- 

LITTLE-A 

O.OOOOOOOF.  +  OO 

LITTLE-B 

0.5110644 

BIG-A 

0 . 6690068 

BIG-B 

O.OOOOOOOE+OO 

GOAL-STATE-LOW-1 

O.OOOOOOOE+OO 

PRIORITY-LOW-i 

O.OOOOOOOE+OO 

GOAL-STATE-LOW-2 

O.OOOOOOOE+OO 

PRIORITY-LOW-2 

5.000000 

GOAL-STATE-HIGH-1 

I .500000 

PRIORITY-HIGH-1 

50.00000 

GOAL-STATE-HI GH-2 
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Table  III-5  (continued) 


7.000000 

PRIORITY-HIGH-2 

5.000000 

GOAL 

-0. 1000000E 
0. COOOOOOE 

+  00 

HHI|M 

O.OOOOOOOE+OC 

LITTLE-A 

O.OOOOOOOE+OO 

LITTLE-B 

0.4463566 

BIG-A 

0.6642079 

BIG-B 

O.OOOOOOOE+OO 

GOAL-STATE-LOW- 1 

O.OOOOOOOE+OO 

PRIORITY-LOW-1 

O.OOOOOOOE+OO 

GOAL-STATE-LOW-2 

O.OOOOOOOE+OO 

PRIORITY-LOW-2 

5.000000 

GOAL-STATE-HIGH-1 

1.300000 

PRIORITY-HIGH-1 

50.00000 

GOAL-STATE-HIGH-2 

6.000000 

PRIORITY-HIGH-2 

7.000000 

GOAL 

O.OOOOOOOEfOO 

LITTLE-M 

O.OOOOOOOE+OO 

BIG-H 

1.000000 

LITTLE-A 

1.000000 

LITTLE-B 

1,000000 

BIG-A 

1.000000 

BIG-B 

-1.000000 

GOAL-STATE-LOW-1 

1.000000 

PRIORITY-LOW-1 

-2.000000 

GOAL-STATE-LOW-2 

2.000000 

PRIORITY-LOW-2 

1.000000 

GOAL-STATE-HIGH-1 

1 .ooooco 

PRIORITY-HIGH-1 

2.000000 

GOAL-STATE-HIGH-2 

2.000000 

PRIORITY-HIGH-2 

The  TDA  has  objective  function  one  as  does  the  TCO,  end  he 
considers  all  three  goals  in  task  sequencing. 

2- 3.  Display  Data. 

The  TDA  has  the  same  display  data  as  does  the  TD.  See 
Table  III-3. 

3-0  GROUP  AN/TSQ-73  OPERATORS  (TD1  and  TD2) 

3- 1.  Human  Factors  Parameters. 

Table  III-6  contains  the  human  factors  parameters  for  the 
Group  AN/TSQ-73  (these  operators  are  labeled  TD1  and  TD2.  The 
comments  in  Section  1-1  apply  equally  to  the  data  for  TD1  and  TD2. 
These  operators  are  identical  and  each  have  authority  analogous  to 
the  Battalion  TD. 
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Table  III-6.  TE1  or d  TD2  Human  Factors  Parameters, 


37. 00000 
J .000000 
0  0000000E+00 
O.OOOOOOOE+OO 
1.000000 
C.000G000E+00 
100.0000 
8.000000 
16. 00000 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
57.00000 
O.OOOOOOOE+OO 
6.000000 
360.0000 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
1.000000 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
5.000000 
40.00000 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
1.000000 
1.000000 
8.000000 
1.000000 
3.000000 
1.000000 
2.000000 
1.000000 
O.OOOOOOOE+OO 
4.000000 
1.000000 
0 . 2080000E-01 
0.2080000E-01 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
1.000000 
t. 000000 
O.OOOOOOOE+OO 
360.0000 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
5.000000 
O.OOOOOOOE+OO 
800.0000 
0.5000000E-01 


CORE-TEMPERATURE 

CIO-VALUE 

TIME-ON-TASK 

DAYS-OF-DUTY 

SEARCH-DIMENSIONS 

NUMBER-FIRE-UNITS 

PERCENTAGE-RECOVERY 

PREVIOUS-WORK 

PREVIOUS-REST 

FLASH-INTENSITY 

TARGET-SPEED 

TARGET-TYf E 

TARGET-SIZE 

TARGET-COLOR 

SEARCH-AREA 

BINOCULAR-USAGE 

SLANT-RANGE-TO-TARGET 

TARGET-TRAJECTORY 

TARGET-BAKGRND-COMPLEXITY 

NUM-BACKGROUND-CHARACTERS 

MESSAGE-BACKLOG 

SIGNALS-PER-MINUTE 

HOURS-UORKED-PER-UEEK 

DAYS-UITHOUT-SLEEP 

DAYS-OF-NIGHT-DUTY 

SIMULTANEOUS-TASKS 

CONTRAST-RATIO 

AVE-HOURS-SLEEP 

OBJECTIVE-FUNCTION 

GPALS-CONSIDERED 

TARGET-BRIGHTNESS 

N I 6HTS 

SKY-GROUND-RATIO 

AIRCRAFT-ALTITUDE 

METEOROLOGICAL-RANGE  - 

THRESHOLD-CONTRAST 

TARGET-HEIGHT 

TARGET-WIDTH 

TARGET-DEPTH 

HORIZONTAL-RANGE 

NUM-OF-RESOLUTION-ELEM 

NUM-OF-SUSPECT-AREAS 

AIRCRAFT-SPEED 

FIELD-OF-VIEU 

OBSERVER-OFFSET 

UNUSED 

DISPLAY-TARGET-LOCATION 

TARGET-LOCATION 

DISPLAY-RESOLUTION 

DISPLAY-BACKGROUND-HEIGHT 


Table  II1-6  (continued) 
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0 . 5000000E-01 
0.5000000E-01 
1.330000 
1.000000 
1.000000 
10.00000 
1.000000 
20.00000 
0.1000000 
1.000000 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
1.000000 
20.00000 
240.0000 
20.00000 
-9999.000 
-9999.000 
-9999.000 


DISPLAY-BACKGROUND- WIDTH 

DISPLAY-BACKGROUND-DEPTH 

DISTANCE-TO-DISPLAY 

DISPLAY-HEIGHT 

DISPLAY-WIDTH 

TARGET-NOISE-LEVEL 

TARGET-DURATION 

EXPERIENCE 

SIGNAL-PROBABILITY 

REST-PERIODS 

TASK-ERROR-FACTOR 

TASK-ELEHENT-ERROR-FACTOR 

DAYS-SINCE-PRACTICE 

SENSE-OF-DIRECTION 

SKIN-TEMPERATURE 

TIME-IN-TEMPERATURE 

PREVIOUS-SKIN-TEMPERATURE 

X-SCREEN-CENTER 

Y-SCREEN-CENTER 

SCREEN-RANGE 


3-2.  Goals,  Goal  Priority  Functions,  and  Objective  Parameters. 

TD1  and  TD2  have  goals  six,  seven,  and  eight  from  Figure 
1II-1.  These  operators  respond  to  messages  because  of  goal  seven 
Just  as  do  the  Battalion  operators.  They  also  perform  a  coordina¬ 
tion  function  for  the  Battalions  due  to  goals  six  and  eight  Just  as 
the  Battalions  perform  a  coordination  function  for  their  fire  units. 
The  goal  priority  function  data  for  TD1  and  TD2  is  shown  in  Table 
1II-7  and  Figure  TII-U.  TD1  and  TD2  use  objective  function  one  and 
consider  all  goals  in  task  sequencing. 

3-3.  Display  Data. 

The  TD1  and  TD2  have  the  same  <Jisp3  ~y  data  as  does  the 
TDA.  See  Table  III-3. 


Table  III— 7.  TD1  and  TD2  Goal  Priority  Function  Parameters. 


6.000000 
-0. 1000000E+11 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
2.500000 
0.1659562 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 


GOAL 

LITTLE-M 

BIG-M 

LITTLE-A 

LITTLE-B 

BIG-A  - 

BIG-B 

GOAL-STATE -LOW-1 

PRIORITY-LOW-1 

GOAL-STATE-LOU-2 

PRIORITY-LOW-2 

GOAL-STATE-HIGH-1 

PRIORITY-HIGH-1 


Table  III-7  (continued) 


3 .000000 

GOAL-STATE-HIGH-2 

3.000000 

PRIORITY-KIGH-2 

7.000000 

GOAL 

O.OOOOOOOE+OO 

LITTLE-M 

O.OOOOOOOE+OO 

BIG-M 

1.000000 

LITTLE-A 

1.000000 

LITTLE-B 

1.000000 

BIG-A 

1 .000000 

BIG-B 

-1.000000 

GOAL-STATE-LOW-1 

1.000000 

PRIORITY-LOW-1 

-2.000000 

GOAL-STATE-LOU-2 

2 • 000O0Q 

PRIORITY-LOW-2 

1.000000 

GOAL-STATE-HIGH-1 

1.000000 

PRI0RITY-HI6H-1 

2.000000 

GOAL-STATE-HIGH-2 

2.000000 

PRIORITY-HIGH-2 

8.000000 

GOAL 

-0.1000000E+11 

LITTLE-H 

O.OOOOOOOE+OO 

BIG-M 

O.OOOOOOOE+OO 

LITTLE-A 

O.OOOOOOOE+OO 

LITTLE-B 

9.000000 

BIG-A 

0 • 1602134E-02 

BIG-B 

O.OOOOOOOE+OO 

GOAL-STATE-LOW-1 

O.OOOOOOOE+OO 

PRIORITY-LOW-1 

O.OOOOOOOE+OO 

GOAL-STATE- LOW-2 

O.OOOOOOOE+OO 

PRIORITY-LOW-2 

1.000000 

GOAL-STATE-HIGH-1 

9.000000 

PRIORITY-HIGH-1 

2.000000 

GOAL-STATE-HIGH-2 

9.010000 

PRIORITY-HIGH-2 
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OPERATOR  COAL  SPECIFICATION 


IV 


ENVIRONMENTAL  DATA 


Table  IV— 1  contains  the  AH/TSQ-73  environmental  state  vector. 

'Che  various  parameters  in  this  vector  are  explained  in  Polito  (1983a). 
The  user  should  note  that  the  default  sampling  option  is  three 
(deterministic,  moderated).  The  Battalion  and  Group  AH/TSQ-73  system 
modules  have  identical  default  environmental  state  vectors.  The  x, 
y,  and  z  positions  are  set  when  uhe  module  is  copied  into  a  parti¬ 
cular  command  and  control  structure. 

Table  IV-1.  The  Environmental’ State  Vector. 


23.00000 
O.OOOOOOOg+OO 
0.0000000^+00 
O.OOOOOOOE+OO 
1.000000 
2.000000 
O.OOOOOOOE+OO 
0.0000000E+00 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOCE+OO 
O.OOOOOOOE+OO 
3.000000 
22.00000 
50.00000 
6.000000 
45.00000 
50 . 00000 
2.000000 
O.OOOOOOOE+OO 
10.00000 
O.OOOOOOOE+OO 


POJNTER-TO-HF-DATA 

SYSTEM-MODE 

OPERATOR-MODE 

UNUSED 

METH0D-0F-C0NTR0L 

WEAPONS-CONTOL-STATUS 

UNUSED 

INITIAL-AMMUNITION-HOT 

INITIAL-AMMUNITION-COLD 

UNUSED 

UNUSED 

UNUSED 

UNUSED 

UNUSED 

UNUSED 

UNUSED 

UNUSED 

UNUSED 

X-POSITION 

Y-POSITION 

Z-POSITION 

SAMPLING-OPTION 

DRY-BULB-TEMPERATURE 

RELATIVE-HUMIDITY 

AIR-MOVEMENT-RATE 

NOISE-LEVEL 

WORKING-AREA- ILLUMINATION 

NUMBER-ON-DUTY 

VIBRATION 

AMBIENT-VAPOR-PRESSURE 

NOISE-PREDICTABILITY 


V 


OPERATOR  TASKS 


AN/TSQ-7'3  operator  tasks  are  giver  below.  Each  task  is  number¬ 
ed  and  has  a  title.  A  brief  description  of  each  task  is  given  here 
and  the  operator  that  performs  tne  task  is  identified.  Complete 
descriptions  and  MSAINT  models  of  the  tasks  are  contained  in 
Goodin  &  Walker  (1983). 


Task 

Number 


Title  or  Description 


Operator 


1  Scan  the  screen,  displays,  etc.  -  TD/TDA 

TD  and  TDA  monitor  action  on 

displays  and  the  CRT  for  new 
targets  or  tasks  to  perform. 

2  Cancel  Sceondary  Assignment  (BN  TD 

only)  -  The  TD  cancels  a  secon¬ 
dary  assignment  made  to  a  fire 

unit . 

3  Send  Terminate  Commands  -  The  TD  TD 

of  the  Group  or  Battalion  Q-73 

sends  a  CEASE  ENGAGED  or  HOLD 
FIRE  command  to  a  lower  echelon 
of  command. 

U  Clear,  Hold  Fire,  Effective,  or  TD 

Status  (BN  only)  -  The  Battalion 
Q-73  receives  information  from  the 
*•  IHAWK  fire  unit  concerning  status 

(active  or  inactive),  engagement 
effectiveness,  etc. 

5  Perform,  Hooking  Procedure  -  The  TD/TDA 

operator  will  number  hook  all  sites 
and  fire  units  and  will  position 
hook  all  tracks. 

7  Enter  ID  Data  (BN  only)  -  The  TDA  TDA 

enters  the  results  of  the  IFF  pro¬ 
cedure  (see  Task  8). 

8  Interrogate  A  Target  (BN  only)  -  The  TDA 

TDA  performs  the  procedure  to  identify 

a  target  as  friend,  foe,  or  neutral. 
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Title  or  Description  Operator 

10  Send  Command  Message  (BN  only)  -  TD 

The  TD  gives  permission  to  fire  on 
a  target  assigned  to  a  fire  unit 
by  the  Q-73. 

15  Assign  Weapons  (BN  only)  -  The  TD  TD 

assigns  a  high  threat  target  to 
one  of  the  fire  units. 

20  Receive  Command  (EN  only)  -  The  TD/TDA 

operators  receive  a  CEASE  ENGAGED 
command  from  a  higher  echelon  of 
command. 

22  Clear  Alerts  (BN  only)  -  The  TD  TD 

will  perform  the  actions  necessary 
to  clear  the  alert  in  question. 

26  Receive  Miscellaneous  Messages  -  A  TD 

zero  time  task  used  to  receive  any 
miscellaneous  messages. 

30  Task  Sequencing  TD/TDA 


Task 

Number 


3 

1 

1 
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VI.  .  OTHER  FEATURES 


1- 0  IFF  ; 

FUNCTION  IFFQ  (Goodin  &  Walker  1983)  determines  the  out¬ 
come  of  an  IFF  challenge.  Currently  Ic  is  assumed  that  the  IFF 
is  100/S  accurate.  This  can  easily  be  changed  by  re-writing  IFFQ. 

FUNCTION  IFMODQ  (Goodin  &  Walier  1983)  determines  what 
IFF  mode  is  selected  by  the  TDA.  Currently,  mode  2  is  always 
selected.  More  complex  selection  processes  can  be  represented 
by  re-*writing  IFMODQ. 

2- 0  HOOKING 

l 

The  current  model  assumes  that  tracks  are  always  position 
hookea  and  that  sites  (e-g,,  firs  units)  are  number  hooked.  This 
assumption  is  manifested  by  setting  information  attributes  at  the 
nodes  prior  to  performing  the  hookihg  task.  More  complex  selec¬ 
tions  can  be  represented  by  re-writing  these  programs  (e.g.,  T15W). 

3- 0  ASSIGNING  TRACKS  TO  FIRE  UNITS  (TASK  15) 

The  current  model  assumes  that  the  TD  selects  tracks  to  assign 
himself.  He  does  not  use  track  assignments  from  the  ADF.  See  the 
network  and  user  code  for  Task  15  (Goodin  &  Walker  1983  ). 

U-0  '{RACK  INITIATION  AND  IDENTIFICATION 

The  current  model  assumes  auto-initiate  and  manual  identi¬ 
fication  modes.  Thus  goal  five  is  not  operative.  SUBROUTINE  GEV5Q 
(Goodin  &  Walker  1983)  which  evaluates  the  goal  state  for  this 
goal  isimulates  the  auto-initiate  activity. 
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VII. 


STATISTICS 


Figure  VTII-1  shows  the  statistics  mainteined  "by  the 
AN/TSQ-73  system  module.  These  statistics  are  ir.  addition  to 
the  task  fraction  statistics  collected  by  M0PAD3  for  all  system 
modules. 
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Standard  MOPADS  Terminology 


AIR  DEFENSE  SYSTEM 

A  component  of  Air  Defense  vhich  includes 
equipment  and  operators  and  for  vhich 
technics!  and  tactical  training  arerequiTed. 
Examples  are  HAWK  and  the  AH/TSQ-73. 

AIR  DEFENSE  SYSTEM 
MODULE 

Models  of  operator  actions  and  equipment 
characteristics  for  Air  Defense  Systems  in 
the  MOPADS  software.  These  models  are  pre¬ 
pared  vith  the  SAINT  simulation  language. 

Air  Defense  System  Modules  include  the 

SAINT  model  and  all  data  needed  to  com¬ 
pletely  define  tosh  element  tinea,  task 
sequencing  requirements,  and  human  factors 
influences. 

AIR  SCENARIO 

A  spatial  and  temporal  record  of  aerial 
activities  and  characteristics  of  an  air 
defense  battle.  The  Air  Scenario  includes 
aircraft  tracks,  safe  corridors,  ECM,  and 
other  aircraft  and  airspace  data.  See 
also  Tactical  Scenario. 

BRANCHING 

A  term  used  in  the  SAINT  simulation  lang¬ 
uage  to  mean  the  process  "by  vhich  TASK  nodes 
are  sequenced.  At  the  completion  of  the 
simulated  activity  at  a  TASK  node,  the 
Branching  from  that  node  determines  vhich 
TASK  nodes  trill  be  simulated  next. 

DATA  BASE  CONTROL 
SYSTEM 

That  part  of  the  MOPADS  software  vhich 
performs  all  direct  communication  vith  the 
MOPADS  Data  Base.  All  information  transfer 
to  and  from  the  data  base  is  performed  by 
invoking  the  subprograms  which  make  up  the 
Data  Base  Control  System. 

DATA  SOURCE 

SPECIALIST 

A  specialist  in  obtaining  and  interpreting 
Army  documentation  and  other  data  needed  to 
prepare  Air  Defense  System  Modules. 
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ENVIRONMENTAL 

STATE  VARIABLE 

An  element  of  an  Environmental  State 

Vector. 

ENVIRONMENTAL 

STATE  VECTOR 

An  array  of  values  representing  conditions 
or  characteristics  that  may  affect  more 
than  one  operator.  Elements  of  Environmen¬ 
tal  State  Vectors  may  change  dynamically 
during  a  MOPADS  simulation  to  represent 
changes  in  the  environment  conditions. 

MODERATOR  FUNCTION 

A  mathematical/logical  relationship  which 
alters  the  nominal  time  to  perform  an  opera¬ 
tor  activity  (usually  a  Task  Element).  The 
nominal  time  is  changed  to  represent  the 
operator's  capability  to  perform  the 
activity  baaed  on  the  Operator's  State 
Vector. 

MDPADS  DATA  BASE 

A  computerized  data  base  designed  specifi¬ 
cally  to.  support  the  MOPADS  software.  The 
MOPADS  Data  Base  contains  Simulation  Data 
Set(s).  It  communicates  interactively  vith 
MOPADS  Users  during  pre-  and  post-run  data 
specification  and  dynamically  vith  the  SAINT 
software  during  simulation. 

MOPADS  MODELER 

An  analyst  vho  -will  develop  Air  Defense 
System  Modules  and  modify/ develop  the 

MOPADS  software  system. 

MOPADS  USER 

An  analyst  vho  vill  design  and  conduct  simu¬ 
lation  experiments  vith  the  MOPADS  software. 

MSAINT 

(MOPADS/SAINT) 

The  variant  of  SAINT  used  in  the  MOPADS 
system.  The  standard  version  of  SAINT  ha3 
been  modified  for  MOPADS  to  permit  share¬ 
able  subnetworks  and  more  sophisticated 
interrupts.  The  terms  SAINT  and  MSAINT  are 
used  interchangeably  when  no  confusion  vill 
result.  See  also,  SAINT. 
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OPERATOR  STATE 
VARIABLE 


One  element  of  an  Operator  State  Vector 


OPERATOR  STATE 

VECTOR 

An  array  of  values  representing  the  condi¬ 
tion  and  characteristics  of  an  operator  of 
an  Air  Defense  System.  Many  values  of  the 
Operator  State  Vector  will  change  dynamically 
during  the  course  of  a  MOPADS  simulation  to 
represent  changes  in  operator  condition. 

OPERATOR  TASK 

An  operator  activity  identified  during 
weapons  system  front-end  analyses.  i 

SAINT 

The  underlying  computer  simulation  language 
used  to  model  Air  Defense  Systems  in  Alt 
Defense  System  Modules.  SAMT  is  an  acronym 
for  Systems  Analysis  of  Integrated  Network* 
of  Tasks.  It  is  a  well  documented  language 
designed  specifically  to  represent  human 
factors  aspects  of  man /machine  systems. 

See  also  MSAHJT. 

SIMULATION  DATA  SET 

The  Tactical  Scenario  plus  all  required 
simulation  initialization  and  other  experi¬ 
mental  data  needed  to  perform  a  MOPADS 
simulation.  f 

SIMULATION  STATE 

At  achy  instant  in  time  of  a  MOPADS  simula¬ 
tion  the  Simulation  State  is  the  set  of 
veins s  of  all  variables  in  the  MOPAD£(  soft¬ 
ware  and  the  MOPADS  Data  Base.  1. 

1  1 

SYSTEM  MODULES 

See  Air  Defense  System  Modules. 

The  Air  Scenario  plus  specification  of 
critical  assets  and  the  air  defense  con¬ 
figuration  (number,  type  and  location  of 
weapons  and  the  cummand  and  control  system). 


TACTICAL  SCENARIO 


TACTICAL  SCENARIO  * 
COMPONENT 

An  element  o f  a  Tactical  Scenario,  e.g. , 
if  a  Tactical  Scenario  contain*  several 
Q-T3'*»  each  on*  is  a  Tactical  Scenario 
Component. 

TASK 

Se*  Operator  Task. 

TASK  ELEMENTS 

Individual  operator  actions  vhich,  vben 
grouped  appropriately,  make  up  operator 
tasks.  Task  elements  are  usually  repre¬ 
sented  by  single  SAdT  TASK  nodes  in  Air 
Defense  System  Modules. 

TASK  NODE 

A  modeling  symbol  used  in  the  SAIBT  simula¬ 
tion  language.  A  TASK  node  represents  an 
activity;  depending  upon  the  modeling  cir¬ 
cumstances,  a  TASK  node  may  represent  an 
individual  activity  such  as  a  Task  Element, 
or  it  may  represent  an  aggregated  activity 
such  as  an  entire  Operator  Task. 

TASK  SEQUENCING 
MODERATOR 

FUNCTION 

A  mathematical/logical  relationship  vhich 
selects  the  next  Operator  Task  vhich  an 
operator  vill  perform.  The  selection  ia 
based  upon  operator  goal  seeking  character¬ 
istics. 

MOFADS  Abbreviations 

CSMP 


Common  bystem  Module  Programs 


I.  SYSTEM  DESCRIPTION 


1-0  THE  CONTROL  SYSTEM  MODULE 

The  control  system  module  is  a  SAINT  network  model  similar  in 
structure  to  Air  Defense  System  Modules.  It  is  included  automatically 
in  every  MOPADS  simulation  by  the  MOPADS  software,  and  its  purpose  is 
to  control  the  movement  of  aircraft  in  the  simulation.  There  are  no 
operators  in  this  system  module.  The  small  network  which  makes  up 
this  module  is  used  solely  to  schedule  aircraft  arrivals,  checkpoints 
and  departures  from  the  simulation.  It  also  schedules  the  end  of  the 
simulation. 

2-0  THE  COMMON  SYSTEM  MODULE  PROGRAMS 

The  Common  System  Module  Programs  (CSMP)  software  module  is  a 
collection  of  utility  programs  used  by  all  of  the  MOPADS  system 
modules.  These  programs  perform  high  level  functions,  so  they  are 
not  included  in  the  MOPADS  utilities,  see  Polito  &  Goodin  (1983),  and 
many  of  them  do  not  involve  the  MOPADS  data  base  directory,  so  they 
are  not  included  in  the  Data  Base  Application  Program  (DBAP),  Polito 
(1983a).  These  programs  are  described  in  Section  VIII  of  this 
document . 
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II. 


OVERVIEW  OF  THE  SAINT  MODEL 


The  need  for  the  control  system  module  arises  from  the  way 
tracks  are  handled  by  MOPADS .  Aircraft  flight  paths  are  represented 
as  piece-vi3e  linear  segments.  Each  segment  represents  a  portion  of 
the  flight  path  along  which  the  aircraft  parameters  (speed,  direction, 
etc.)  remain  constant.  The  transition  points  between  segments  are 
called  checkpoints. 

All  of  the  aircraft  tracks  are  stored  in  the  MOPADS  data  base 
prior  to  the  simulation,  Polito  (1983b).  There  may  be  many  tracks, 
and  it  is  impractical  to  provide  array  storage  to  hold  all  segments 
of  all  tracks  in  main  memory  simultaneously.  The  control  system 
module  performs  two  functions  to  manage  the  aircraft  track  data. 

1.  It  periodically  scans  the  track  information  in  the 
data  base  for  tracks  which  will  initiate  in  the 
near  future.  For  each  such  track  it  finds,  it 
schedules  its  initiation  checkpoint. 

2.  When  a  track  reaches  a  checkpoint,  it  reads  the 
data  for  the  next  segment  from  the  data  base  and 
schedules  the  next  checkpoint. 

Between  checkpoints  the  positions  of  the  aircraft  are  updated 
automatically  by  the  continuous  modeling  capbility  of  SAINT.  The 
equations  of  motion  of  the  aircraft  are  represented  by  difference 
equations.  This  is  adequate  since  aircraft  parameters  are  constant 
between  checkpoints. 

In  addition  to  aircraft  data  management,  the  control  system 
module  also  schedules  the  end  of  the  simulation.  The  end  time 
specified  by  the  user  is  used  in  a  small  subnetwork  to  cause  a 
SAINT  sink  node  completion  at  toe  appropriate  time. 


III.  MODEL  DESCRIPTION  FORMS 


1- 0  ENTITIES 

The  control  system  mrdule  create-!  an  entity  that  periodically 
examines  the  data  base  for  aircraft  that  will  initiate  in  the  next 
period.  It  also  creates  an  entity  for  each  track  that  it  finds. 
These  track  entities  complete  a  task  each  time  the  aircraft  reaches 
a  checkpoint.  Finally,  one  entity  is  created  to  end  the  simulation 
at  the  appropriate  time. 

2- 0  RESOURCES 

No  SAINT  resources  are  used. 

3- 0  VARIABLES 

The  control  system  module  has  no  internal  COMMON  variable. 

U-0  MONITORS 

The  control  system  module  has  no  Monitor. 
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5-0  TASK  DESCRIPTIONS 


There  are  si*  task  nodes  in  the  Control  System  Module. 


1 


i 
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NAHEl  Polito  AIR  DEFENSE  STSTEH  HODULEi  CONTROL 

DATE  I  11-10-83  PROJECT  l  MOFADS 


frr 


Riley  Goodin  AIR  DEFENSE  SYSTEM  HODULEl  CONTROL 

5-16-83  PROJECT  i  MOPADS 


SKIU  RE.GU1R(HF,MIS  TASK  SPECIFIC  MIA  HSA1MT  RESOURCE 

(CAfEUORTyUElGHI)  (CODE,  VALUE)  REQUIREMENTS 


NAHEt  Polito  AIR  DEFENSE  STIIEH  MODULE l  CONTROL 

DA  IE  i  .11-10-83  PROJECT  l  MOPADS 


6-0  STATISTICS 


User  time  persistent  statistics  and  count  statistics  are 
collected  in  the  control  system  module. 
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7- 0  USER  FUNCTIONS 

Three  execution  time  user  functions  are  uf.ed  in  the  control 
system  module.  No  initialization  (input)  user  f’-jactions  are  used. 

8- 0  MODERATOR  FUNCTIONS 

No  moderator  functions  are  used  by  the  control  system  module. 
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IV.  USER  WRITTEN  SUBPROGRAMS 


1- 0  DATA  STRUCTURE 

The  control  system  module  has  no  internal  data  structure  that 
is  common  over  subprograms .  All  data  is  passed  to  and  from  sub¬ 
programs  by  formal  parameters. 

2- 0  FLOW  OF  CONTROL 

The  entry  point  to  the  user  written  programs  for  the  control 
system  module  is  through  the  MSAINT  user  function,  USERF.  USERF 
calls  the  user  function  for  the  control  system  module,  USERFC. 

For  user  function  one,  USERFC  calls  SUBROUTINE  CHKTRC  Which 
schedules  the  next  checkpoint  for  a  track.  For  user  function  two, 
USERFC  calls  SUBROUTINE  INTTRC  which  checks  for  new  tracks  to  enter 
from  the  data  base.  k  i 

No  initialization  of  the  control  system  module  is  needed,  and 
no  processing  with  SUBROUTINE  UTASK  is  performed.  Therefore, 
SUBROUTINE  TNITC  and  OTCNLC  are  present  but  have  no  executable  code. 

Some  of  these  programs  are  called  by  SUBROUTINE  STATE  between 
checkpoints  to  determine  if  a  track  is  visible  to  any  of  the  air 
defense  system's  viewers  (radars).  More  discussion  of  this  topic  is 
given  in  Section  5-0  below. 

3- 0  FILES 

The  Control  System  Module  does  not  open  or  close  any  external 
file.  Certain  error  messages  are  written  directly  to  the  MOPADS 
line  printer  output  file,  and  the  MOPADS  data  base  is  indirectly 
accessed  with  data  base  application  programs,  Polito  (1983a). 

U-0  SUBPROGRAMS  1 

!  1 

Internal  documentation  for  the  subporgrams  that  make  up  the 
Control  System  Module  is  shown  on  the  following  pages. 
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SUBROUTINE  CHKTRC  (UF) 

C '"NODULE t  NOPADS  CONTROL  SYSTEM  NODULE 
C— REFERENCE*  HOPADS  VOLUHE  5.19 
C 

CmPURPOSE*  THIS  SUBROUTINE  IS  CALLED  BY  FUNCTION  USERF  TO  DETERMINE 
C  THE  TINE  THAT  UILL  ELAPSE  BEFORE  THE  NEXT  CHECKPOINT  FOR 

C  AN  AIRCRAFT  IN  THE  AIR  SCENARIO. 

C 

C**OUTPUT  PARAMETERS*  UF-TINE  TO  FLY  TO  NEXT  CHECKPOINT 
C 


SUBROUTINE  CKSVC(NTCQL,X,IYN> 

C— NODULE*  HOPADS  CONTROL  SYSTEM  NODULE 
C— REFERENCE:  NOPADS  VOLUME  5.19 
C— PURPOSE* 

C  CKSVC  UILL  CHECK  TO  SEE  IF  THE  SAME  VIEWER  WHICH  PREVIOUSLY 
C  COULD  SEE  A  TRACK  CAN  STILL  SEE  II 
C— INPUT  PARAMETERS* 

C  NTCOL-TRACK  COLUMN  IN  NTRACK 
C  X(3>— CURRENT  POSITION  OF  THE  TRACK 

C— OUTPUT  PARAMETERS* 

C  IYN-YES/NO 

C  1-YES,  THE  SAME  V1EUER  CAN  STILL  SEE  THE  TRACK 

C  2-NO,  IT  CAN'T 

C  IF  THE  TRACK  UAS  PREVIOUSLY  HOT  IN  ANY  VIEWER'S  VIEU, 

C  IYN  UILL  ALWAYS  BE  2. 


SUBROUTINE  CKVUC(NCOL,X, IYN, ALT, SECTOR, PROB) 

— MCDULEt  NOPADS  CONTROL  SYSTEM  MODULE 
--REFERENCE:  HOPADS  VOLUME  5.19 
—PURPOSE* 

GIVEN  A  VIEUER  AND  A  POINT,  CKVUC  WILL  DETERMINE  IF  THE 
VIEUER  CAN  SEE  THE  POINT. 

—  INPUT  PARAMETERS! 

NCOL-COLUHN  IN  THE  NSITE/XSITE  ARRAY  OF  THE  VIEUER 
X(3)-X,Y,Z  POSITION  OF  THE  POINT  THE  VIEUER  IS  TO  SEE 
—OUTPUT  PARAMETERS: 

IYN-YES/NO 

1- YES,  THE  VIEUER  CAN  SEE  THE  POINT 

2- NO,  IT  CAN'T  SEE  THE  POINT 

ALT < 2 ) -MIN  AND  HAX  ALTITUDE  THE  VIEUER  CAN  SEE 

SECTOR (2) -COMPASS  AZIMUTH  OF  THE  SECTOR  OF  INTEREST  OF  THE 


C  VIEWER.  IYN  IS  NOT  RELATED 

C  TO  SECTOR  IN  ANY  WAY.  SECTOR  IS  PROVIDED  AS 

C  INFORMATION  ONLY. 

C  PRQB-PROBABILITY  THAT  THE  VIEWER  WILL  ACQUIRE  A  NEU  TARGET. 


SUBROUTINE  CNREC  (KOBE) 

C— MODULE:  MOPADS  CONTROL  SYSTEM  MODULE 
C— REFERENCE:  MOPADS  VOLUME  5.19 
C 

C**PURPOSE:  THIS  SUBROUTINE  MAY  BE  USED  FOR  SPECIAL  OUTPUT  FOR 
C  CONTROL  SYSTEM  MODULE  ERRORS. 

C 

C**INPUT  PARAMETERS:  KQDE=ERROR  CODE  VALUE  <8000-8999) 

C 


SUBROUTINE  EOSPC ( ICOL , NTRKCL r NTR r ASCEN,NASC) 

C — MODULE:  MOPADS  CONTROL  SYSTEM  MODULE 
C— REFERENCE:  MOPADS  VOLUME  5.19 
C— PURPOSE: 

C  EOSPC  WILL  PERFORM  END-OF-SEGHENT  PROCESSING  FOR  TRACKS. 
C  EOSPC  CHECKS  TO  SEE  IF  THE  END  OF  SEGMENT  IS  A  TARGET 

C  AND  IF  THE  TRACK  IS  HOSTILE.  IF  SO,  IT  WILL  CHECK  THE 

C  PROBABILITY  OF  DESTRUCTION  TP  SEE  IF  THE  TARGET  IS 

C  DESTROYED.  IF  SO,  IT  UILL  SET  THE  STATUS  AS  INACTIVE. 

C — INPUT  PARAMETERS: 

C  ICOL-COLUMN  IN  NTRACK  OF  THE  TRACK 

C  NT RKCL(NTR) -CONTENTS  OF  COLUMN  ICOL  OF  NTRACK 

C  ASCEN(NASC ) -CONTENTS  OF  CURRENT  ROU  OF  THE  DATA  BASE  FOR 

C  THE  SEGMENT  JUST  COMPLETED. 
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SUBROUTINE  FDVUC ( NTCOL r NVCOL ) 

C — MODULE:  NOPADS  CONTROL  SYSTEM  NODULE 
C— REFERENCE:  NOPADS  VOLUME  5.1? 

C— PURPOSE: 

C  FDVUC  UILL  FIND  A  VIEWER  THAT  CAN  SEE  A  SPECIFIED  TRACK  IF  SUCH 
C  A  VIEUER  EXISTS. 

C — INPUT  PARAMETERS: 

C  NTCOL-TRACK  COLUMN  NUMBER  IN  NTRACK 

C~ OUTPUT  PARAMETERS: 

C  NVCOL-VIEUER  COLUMN  NUMBER  IN  NSITE  THAT  CAN  SEE  THE  TRACK. 

C  ZERO  IF  NONE.  IF  THE  TRACK  UAS  PREVIOUSLY  SEEN  BY  A 

C  PARTICULAR  VIEUER  ON  INPUT  THEN  NVCOL  UILL  BE  THE  SAME 

C  VIEUER (ASSUMING  THAT  IT  CAN  STILL  SEE  THE  TRACK) 

C  FDVUC  DOES  NOT  CHANGE  ROU  10  OF  NTRACK  TO  INDICATE 

C  THE  VIEUER  UHICH  SEES  THE  TRACK. 


SUBROUTINE  INITC(NRUN) 

C— MODULE:  MOPADS  CONTROL  SYSTEM  MODULE 
C — REFERENCE:  MOPADS  VOLUHE  5.19 
C — PURPOSE: 

C  INITC  IS  THE  INITIALIZATION  PROGRAM  FOR  THE  CONTROL  SYSTEM 

C  MODULE. 

C~ INPUT  PARAMETERS: 

C  NRUN-RUN  NUMBER 

C  O-INITC  IS  BEING  CALLED  AT  THE  START  OF  THE  SIMULATION 

C  PRIOR  TO  ANY  RUNS 

C  N-NRUN  IS  BEING  CALLED  PRIOR  TO  THE  BEGINNING  OF 

C  RUN  N 


SUBROUTINE  INTTRC  (UF ; 

C— HODULE:  MOPADS  CONTROL  SYSTEM  MODULE 
C — REFERENCE:  MOPADS  VOLUME  5.19 
C 

C**PURPOSE:  THIS  SUBROUTINE  IS  CALLED  BY  THE  USERF  FUNCTION  TO 

C  SCHEDULE  TRACKS  INTO  THE  AIR  SCENARIO. 

C  INTTRC  EXAMINES  THE  TRACK  DATA  IN  THE  DATA  BASE 

C  AND  ENTERS  TRACKS  THAT  UILL  INITIATE  IN  THE 

C  NEXT  DELT  TIME  UNITS. 

C 

CMOUTPUT  PARAMETERS:  UF =T HE  RESULTING  VALUE  OF  THE  USER  FUNCTION 
C  VARIABLE 

C  0-A  TRACK  HAS  BEEN  FOUND  THAT  UILL 

C  INITIATE  BETWEEN  TNOU  AND  TNOU+DELT 


C  DELT-ALL  TRACK  IN  THE  NEXT  DELT  TIME  INT 

C  INTERVAL  HAVE  BEEN  PROCESSED. 

C  SCHEDULE  THE  NEXT  CALL  TO  INTTRC 

C  DELT  TIME  UNITS  IN  THE  FUTURE. 

C 


SUBROUTINE  UTCNLCtNT ,NPLACE) 

C— MODULE:  MOPADS  CONTROL  SYSTEM  MODULE 
C--REFERENCE:  MOPADS  VOLUME  5.19 
C— PURPOSE: 

C  UTCNLC  U2LL  PROCESS  CALLS  FROM  UTASK  FOR  THE  CONTROL  SYSTEM 

C  MODULE. 

C— INPUT  PARAMETERS: 

C  NT-TASK  NODE  NUMBER 

C  NPLACE-TASK  NODE  OCCURANCE  TIME (SEE  UTASK) 


FUNCTION  USERFC  (IP) 

C--MODULE:  MOPADS  CONTROL  SYSTEM  MODULE 
C--REFERENCE:  MOPADS  VOLUME  5.19 
C 


C**PURPQSE:  THIS  SUBROUTINE  IS  USED  TO  CALCULATE  THE  VALUE  OF  USERFC 
C  DEPENDIN3  ON  THE  VALUE  OF  IP. 


C** INPUT  PARAMETERS: 

C 

C 

c 

c 

C*+0UTPUT  PARAMETERS: 
C 


IP=THE  FUNCTION  NUMBER 

1  IS  AN  AIRCRAFT  CHECKPOINT 

2  IS  AN  AIRCRAFT  INITIATION 

3  IS  THE  TOTAL  TIME  TO  BE  SIMULATED 

USERFC=THE  VALUE  OF  THE  PARTICULAR  USER  FUNCTION 
CALLED 


FUNCTION  USERMC < ICODE ) 

C — MODULE:  MOPADS  CONTROL  SYSTEM  MODULE 
C— REFERENCE:  MOPADS  VOLUME  5.19 
C— PURPOSE: 

C  USERNC  EVALUATES  THE  INPUT  USER  FUNCTION  FOR  THE  CONTROL 

C  SYSTEM  MODULE 

C — INPUT  PARAMETERS: 

C  ICGDE-uSER  FUNCTION  CODE 

C--OUTPUT  PARAMETERS: 

C  USERNC-VALUE  OF  THE  USER  FUNCTION 
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USER  INSTRUCTIONS 


As  discussed  earlier,  same  of  the  programs  in  the  User 
Written  Programs  are  called  primarily  from  SUBROUTINE  STATE.  These 
programs  are  concerned  with  determining  which  viewers  (radars)  can 
’’see”  the  tracks: 


CKSVC 


CKVWC 


FDVWC 


Finally,  at  the  end  of  each  segment,  SUBROUTINE  EOSPC  is 
called  from  CHKTRC  to  perform  end-of-segment  processing. 

6-0  ERROR  PROCESSING 

The  Control  System  Module  writes  a  few  informative  warning 
messages  directly  to  the  MOPADS  line  printer  output  file.  These 
are  non-fatal  warnings  that  have  to  do  with  anamolies  detected  in 
the  air  scenarios. 

Other  errors  are  processed  with  the  MSAINT  error  processing 
program,  SERR.  Error  codes  8000-8999  axe  reserved  for  the  Control 
System  Module.  The  error  codes  defined  at  this  time  are  shown  below. 


This  program  determines  if  the  same 
viewer  which  could  previously  see  a 
track  can  still  see  it.-  Use  of  this 
program,  is  more  efficient  than  doing 
a  complete  examination  of  viewers. 

Checks  one  viewer  and  one  track  to 
determine  if  the  viewer  can  see  the 
track. 

Finds  a  viewer  which  can  see  a  parti¬ 
cular  track. 


Error  Code 


Error  Conditions 


Subprogram(s) 


8000  Track  Storage  Arrays  Full 
(NTRACK,  SS,  SSL) 

8001  NTRID  and  NTRED2  arrays  full 


INTTRC 

INTTRC 


8002  A  Track  from  the  data  base  is  CHKTRC 

not  of  the  correct  type  (i.e.. 

Hostile,  Friendly,  Other) 


8003 


Invalid  User  Function  Code 


USERFC,USERNC 


Finally,  some  errors  that  involve  data  from  the  data  "base  are 
processed  with  the  DBAP,  Polito  (1983a),.  error  processing  program, 
ERRORA.  These  errors  have  a  text,  message  displayed  and  print  out 
the  offending  data  base  entry.  See  Polito  (1983a)  for  a  description 
of  ERRORA. 

7-0  COMMON  VARIABLE  DEFINITIONS  . 

The  Control  System  Module  has  no  variables  in  COMMON  areas. 


* 

I 


f 


* 


1 
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V.  LISTING  OF  SAINT  NETWORK  DATA  INPUT 


GEN,CQNTRQL,5. 12,1983,1000* 

P0P,O, 0,10,4,20* 

DIS,  1 , CO, .001 ♦ 

DIS,2,C0,0.0* 

UTI'I , AOGNHQST ,0.0* 

UTI, 2,AVGNFRND , 0.0* 

UTI,3,AVGNUNKN,0.0* 

UTI,4,AVGNTRKS,0.0* 

*  I 

♦TRACK  HANDLING  TASKS 

* 

TAS.l.STA  !TTR,0,9999,DS,2, < 10>S0* 

DET ,1,2*  1 

♦  i 

TAS, 2, INITIATE, i,1,UF, 2* 

CAL,2,2,AEV,0.0,3,IA, ,2,AL9,0.0,3,1A,,3,ALV,0.0,3,1A* 

* 

TAS , 3,CHKPQINT , 1 , 1 ,UF , 1 , * 

CFI,3,3,AGV,Q.Or3,IA,,4,AEV,O.Qt3,lA*  | 

* 

TAS,4,KILLTRK,1,1,DS,2* 

* 

♦CONTROL  NETWORK  FOR  ENDING  THE  SIHULATION  AT  TINE  TF INK— TSTRTK 
* 

TAS,5,CNTRLTIK,0,9999,DS,2, (10) SO* 

DET, 5,6* 

* 

TAS,6,ENDTINE,1,1,UF,3,(10)SI* 

* 

FIN*  i 


I 
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VI.  NON-SAINT  DATA  REQUIREMENTS 


1- 0  DATA  REQUIREMENTS 

The  Control  System  Module  requires  data  on  the  tracks  which 
make  up  the  air  scenario.  It  also  operates  cm  the  viewer  informa¬ 
tion.  The  track  information  is  used  to  schedule  tracks  into  the 
MOPADS  simulations,  and  to  schedule  each  track's  checkpoints.  The 
viewer  data  is  used  through  calls  from  SUBROUTINE  STATE  to  determine 
which  radars’  can  see  the  tracks. 

2- 0  DATA  SOURCE  AND  DESCRIPTION 

Aircraft  track  information  is  obtained  from  the  MOPADS  data 
base.  The  contents  and  method  of  specifying  this  information  1b 
discussed  in  Polito  (1983b). 

Data  for  the  viewers  (radars)  is  specifying  by  the  user  when 
the  simulation  data  sex  is  created.  A  discussion  of  this  information 
can  be  found  in  Polito  (1983c). 
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VII.  OUTPUT  REPORTS 


The  Control  System  Module  produces  no  separate  output 
reports. 


VIII.  COMMON  SYSTEM  MODULE  PROGRAMS 


1-0  PURPOSE 

As  discussed  earlier,  the  Common  System  Module  Programs  (CSMP) 
contain  programs  used  by  all  of  the  system  modules.  The  MOPADS 
suffix  for  the  CSMP  is  "Y"  so  all  of  the  programs  written  for  this 
software  module  end  in  "Y."  The  MSAT1*T  user  written  programs  are 
also  induced  in  this  module,  so  some  of  the  programs  described  here 
do  not  end  in  "Y."  For  example,  the  MSAINT  programs  ENDIT,  INTLC, 
MODRF,  PRIOR,  STATE,  UACCFT,  UERR,  UIHPT,  USCOND,  USERF,  USERIN, 
USTART,  and  UTASK  are  contained  in  the  CSMP. 

2- 0  DATA  STRUCTURE 

The  CSMP  has  very  little  internal  data  structure  since  it  is 
comprised  mainly  of  programs  each  of  which  performs  a  separate 
function.  It  does,  however,  contain  storage  arrays  for  MOPADS 
count  statistics  and  operator  task  fraction  statistics.  Those 
arrays  are  described  in  Section  8-0  below. 

3- 0  FLOW  OF  CONTROL 

The  CSMP  has  no  internal  structure  of  its  own  and,  therefore, 
has  no  flow  of  control  that  needs  description.  The  programs  are 
called  primarily  as  utilities  from  other  modules. 

U-0  FILES 

The  CSMP  does  not  open  or  close  any  external  files.  Indirect 
access  is  made  to  the  Data  Base  Application  Program  (DBAP),  Polito 
(1983a),  and  the  Data  Base  Control  Systan  (DBCS),  Polito  (1983d), 
thorugh  subprogram  calls. 

5-0  SUBPROGRAMS 

The  following  pages  contain  descriptions  of  all  subprograms 
that  are  part  of  the  CSMP.  Each  program  description  contains  an 
explanation  of  its  purpose,  parameters,  and  alternate  returns. 
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BLOCK  DATA  BLOCKY 

C--HODULE:  NOPADS  COMMON  USER  CODE 
C~ REFERENCEt  NOPADS  VOLUME  5.19 
C--PURPOSE: 

C  BLOCKY  IS  USED  TO  INITIALIZE  COMMON  FOR  THE  COMMON  SYSTEM  MODULE 

C  PROGRAMS.  IN  PARTICULAR,  THE  COUNTER  STATISTICS  FOR  EACH 

C  SYSTEM  NODULE  MUST  BE  LOADED  IN  THIS  fnOGRAH. 


SUBROUTINE  CCOBSY(NT.NPLACE) 


C— NODULE:  NOPAOS  COMMON  USER  COSE 
C— REFERENCE:  HOPADS  VOLUME  5.19 

c  ! 

CMPURPOSE:  THIS  SUBROUTINE,  CALLED  BY  UTASK  FOR  EACH  TASK  NODE. 
C  AT  EACH  TASK  OCCURRENCE  TIME,  FIGURES  OUT  IF  THE 

C  OPERATOR  TASK  CUMULATIVE  TINE  STATISTICS  NEED  TO  BE 

C  NARKED  OR  RECORDED.  IF  SO  THE  APPROPRIATE  ACTION 

C  IS  TAKEN.  I 

C 

CmINPUT  PARANETERSt  NT  -  CURRENT  TASK  NODE  NUMBER 
C  NPLACE  -  TASK  OCCURRENCE  TIME 


SUBROUTINE  CHTDY(NPTRK,ICOL,VAL) 

C — MODULE:  HOPADS  CONHON  USER  CODE 
C— REFERENCE:  NOPADS  VOLUME  5.19 
C— PURPOSE: 

*  C  CHTDY  UILL  CHANGE  ONE  ELEMENT  OF  TRACK  DATA  FOR  A  SPECIFIED 

C  TRACK  IN  THE  TRACK  DATA  DL'S  OF  ALL  ADSM'S 
C -—INPUT  PARAMETERS: 

C  NPTRK-COLUHN  IN  NTRACK  OF  THE  TRACK  IN  QUESTION 

C  ICOL-ELEMENT  OF  THE  TRACK  DATA  LIST  FOR  TRACK  NPTRK  TO 

C  CHANGE 

1  C  VAL-NEU  VALUE  FOR  ELEMENT  ICOL 
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SUBROUTINE  CLMEMY < IDOP) 

C— MODULE:  NOPADS  COMMON  USER  CODE 
C — REFERENCE!  MOPADS  VOLUME  5.19 
C--PURPOSE: 

C  CLMEMY  UILL  CLEAR  AN  OPERATOR'S  STACK  OF  ALL  BUT  THE 

C  CURRENT  TASK.  THIS  IS  USEFUL  TO  DESTROY  AN  OPERATOR'S 

C  MEMORY  AFTER  HE  HAS  DEEN  INTERRUPTED. 

C— INPUT  PARAMETERS: 

C  IDOP-OPERATOR  ID 


SUBROUTINE  COHET(KQDE) 

C— MODULE:  MOPADS  COMMON  USER  CODE 
C— REFERENCE:  MOPADS  VOLUME  5.19 
C — PURPOSE: 

C  COMEY  UII.L  PERFORM  SPECIALIZED  ERROR  OUTPUT  FOR 
C  ERRORS  GENERATED  BY  THE  COMMON  SYSTEM  MODULE 

C  PROGRAMS.  COMEY  IS  CALLED  FROM  UERR. 

C — INPUT  PARAMETERS: 

C  KODE-ERROR  CODE.  CODES  FOR  THE  COMMON  SYSTEM 
C  MODULE  PROGRAMS  ARE  IN  THE  RANGE 

C  7000-7999 


SUBROUTINE  CSTATYINCOP, ISTAT, XINC) 

C— MODULE:  MOPADS  COMMON  USER  CODE 
C — REFERENCE:  MOPADS  VOLUME  5.19 
C— PURPOSE: 

C  CSTATY  UILL  RECORD  OBSERVATIONS  OF  COUNTER  STATISTICS. 

C  COUNTER  STATISTICS  ARE  SIMPLY  ACCUMULATIONS  OF  VALUES 

C  (USUALLY  COUNTS)  THAT  OCCUR  DURING  A  SIMULATION  RUN. 

C  THEY  ARE  REPORTED  THROUGH  THE  MOPADS  DATA  BASE  AT  THE  END 

C  OF  EACH  RUN.  NO  STATISICAL  MEASURES  ARE  GIVEN  (E.G. 

C  STANDARD  DEVIATION)  BECAUSE  ONLY  THE  TOTAL  VALUE  IS 

C  AVAILABLE  FOR  THE  RIJN. 

C  EXAMPLES  ARE  A)  NUMBER  OF  AIRCRAFT  SHOT  DOUN  DURING  A  RUN, 

C  AND  B)  CUMULATIVE  IDLE  TIME  DURING  A  RUN.  SEE  ALSO 

C  BLOCKY,INITY,AND  STDBY. 
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C— INPUT  PARAMETERS! 

C  NCOP-COPY  ROU  NUMBER  OF  THE  COMPONENT  TO  RECORD  AN 
C  OBSERVATION  FOR. 

C  ISTAT-INDEX  OF  THE  STATISIC  TO  BE  RECORDED. 

C  XINC-OBSERVATION  TO  RECORD.  ESSENTIALLY,  CSTATY 
C  ACCUMULATES  THE  XINC'S  AS  FOLLOUS: 

C  CQUNTdSTAT,NCQP)«COUNTdSTAT  ,NCQP)+XINC 

C  AND  REPORTS  COUNTdSTAT ,  NCOP)  AT  THE  END  OF  EACH 

C  RUN. 


SUBROUTINE  CVTKYCNCOPI ,NCTRK,IYN) 

C~ MODULE!  MOPADS  COMMON  USER  CODE 
C— REFERENCE!  MOPADS  VOLUME  5.19 
C— PURPOSE: 

C  CVTKY  UILL  CHECK  TO  SEE  IF  THE  VIEUERS  OF  A  SPECIFIED  AD 
C  UNIT  CAN  SEE  A  PARTICULAR  TRACK. 

C— INPUT  PARAMETERS; 

C  NCOPI-COPY  ROU  NUMBER  OF  THE  UNIT 

C  NCTRK-COLUHN  IN  NTRACK  OF  THE  TRACK 

C— OUTPUT  PARAMETERS! 

C  IYN-YES/NO 

C  1-YES,  THE  TRACK  IS  IN  VIEU  OF  ONE  OF  THE  UNITS  VIEUERS. 

C  2-NO,  IT  ISN'T 


SUBROUTINE  DELTRY5NPTRK) 

C— MODULE;  MOPADS  COMMON  USER  CODE 
C— REFERENCE;  MOPADS  VOLUME  5.1? 

C— PURPOSE! 

C  DELTRY  UILL  DELETE  A  TRACK  FROM  THE  TRACK  DATA  LIST  OF 
C  EVERY  UORKINS  A3SM 
C — INPUT  PARAMETERS: 

C  NPRTK-COLUMN  NUMBER  IN  NTRACK  OF  THE  TRACK  TO  DELETE 


SUBROUTINE  ENDIT'.NRUN) 

C-MODULE:  MOPADS  COMMON  USER  CODE 
C — REFERENCE:  MOPADS  VOLUME  5.19 
C — PURPOSE: 

C  ENDIT  IS  CALLED  AT  THE  END  OF  EACH  ITERATION  TO  PERFORM 
C  ALL  END  OF  RUN  PROCESSING. 

C — INPUT  PARAMETERS! 

C  NRUN-RUN  NUMBER  JUST  COMPLETED 
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FUNCTION  FLTY(f'rC0l,NTC0L) 

C — NODULE:  NOPADS  CONNON  USER  CODE 
C— REFERENCE;  H0PADS  VOLUME  5.1? 

C— PURPOSE; 

C  FLTY  UILL  COMPUTE  THE  FLIGHT  TIME  OF  THE  IHAUK  MISSILE 

C  (MINUTES).  FLTY  DOES  NOT  CHECK  TO  SEE  IF  EITHER  NFCOL  OR 

C  NTCOL  IS  VALID. 

C — INPUT  PARAMETERS: 

C  NFCOL-NFSTOR  COLUMN  OF  THE  FIRE  UNIT 

C  NTCQL-NTRACK  COLUMN  OF  THE  TRACK 


SUBROUTINE  GEVALYUDQP, NADSM,NCOPI ,NGS, IOPR,GS,NNG) 

C-  -MODULE:  MOPADS  COMMON  USER  CODE 
l — REFERENCE:  MOPADS  VOLUME  5.19 
C — PURPOSE: 

C  GEVALY  UILL  EVALUATE  AN  OPERATOR'S  GOAL  STATE  VECTOR 
C 

C — INPUT  PARAMETERS: 

C  IDOP-OPERATOR  ID 

C  NADSM-SYSTEM  MODULE  TYPE 

C  NCOPI-COPY  ROU  NUMBER 

C  NGS-ACTUAL  LENGTH  OF  GS 

C— INPUT/OUTPUT  PARAMETERS: 

C  IOPT < 2 ) —DBA A  OF  THE  OPERATOR  STATE  VECTOR 

C— OUTPUT  PARAMETERS: 

C  GS( NGS) —GOAL  STATE  VECTOR 

C  NNG-THE  NUMBER  OF  GOALS  THE  OPERATORS  OF  THE  SYSTEM  HAVE. 

C  (I.E.  ONLY  THE  FIRST  NNG  ELEMENTS  OF  GS  HAVE  MEANINGFUL 

C  INFORMATION).  IF  THE  OPERATOR  DOES  NOT  HAVE  GOAL  I, 

C  THEN  GS ( I )  =  - 1 .El 0. 


SUBROUTINE  GPRIY ( IDOP,NADSM, NCOPI , G3,NNG, IOPR, GSP) 

C— MODULE:  MOPADS  COMMON  USER  CODE 
C— REFERENCE:  MOPADS  VOLUME  5.1? 

C — PURPOSE: 

C  GPRIY  UILL  EVALUATE  GOAL  PRIORITIES  GIVEN  THE  GOAi.  STATES 
„  FOR  AN  OPERATOR. 

C  —  INPUT  PARAMETERS: 

C  IDOP-OPERATOR  ID 

C  NADSM-SYSTEM  MODULE  TYPE 

C  NCOPI-COPY  ROU  NUMBER 

C  GS (NNG ) -CURRENT  GOAL  STATE  VECTOR 
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C— INPU1 /OUTPUT  PARAMFTEhS: 

C  I0PR(2)-3DAA  OF  THt  C.’ERATOR  STATE  VECTOR 
C— OUTPUT  PARAMETER'* 

C  GSP<NN8>-S0AL  PRIOR  ITT  VECTOR.  1*  THE  OPERATOR  DOES  NOT 
C  HAVE  60AL  i,  THEN  BS?{I5«0. 


SUiROUTir  8S0URT( IOOP,NSHODE) 

C—MODULEj  MOPADS  COMMON  USER  CODE  / 

C— kEFERENCEl  SOPABS  VOLUME  5.19 
C— PURPOSE* 

C  6S0URY  (JILL  RETURN  THE  SOURCE  NODE  UHERE  A  PARTICULAR 
C  OPERATOR  IS  CREATED. 

C — INPUT  PARAMETERS* 

C  IDOP-OPERATOR  10 

C— OUTPUT  PARAMETERS* 

C  NSNOOE— SOURCE  NODE  NUMBER  UHERE  THE  OPERATOR  IS  CREATED 


SUBROUTINE  INITY(NRUN) 

C— MODULE:  MOPADS  COMMON  USER  CODE 
C— REFERENCE*  MOPADS  VOLUME  S.19 
C— PURPOSE* 

C  INI TY  UILL  INITIALIZE  THE  COMMON  SYSTEM  MODULE  PROGRAMS. 
C 

C— INPUT  PARAMETERS* 

C  NRUN-RUN  NUMBER  ABOUT  TO  BE6IN 

C  O-INITY  IS  BEINS  CALLED  PRIOR  TO  PERFORMING  ANY  RUN 

C  N-1NITY  IS  BEIN6  CALLED  PRIOR  TO  RUN  N. 


SUBROUTINE  INTLC 

C— MODULE*  MOPADS  COMMON  USER  CODE 
C— REFERENCE*  MOPADS  VOLUME  5.19 
C~  PURPOSE* 

C  INTLC  IS  THE  STANDARD  5AI“T  UER  INPUT  PROGRAM  FOR  DOING 
C  ANY  REQUIRED  USFR  INITIALIZATION.  IT  IS  NOT  USED  BY 

C  MOPADS.  THIS  IS  A  DUMMY  PROSRAN.  SEE  SUBROUTINES 

C  USTART  AND  INITY  IN  THIS  SECTION. 
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SUBROUTINE  IROilY 

C — MODULE*  HOP ADS  COHHON  USER  CODE 
C— REFERENCES  HOPADS  VOLUME  5.19 
C— PURPOSE: 

C  IR0U1T  UIU  INITIALIZE  ALL  DATA  LISTS  IN  UORKIN6  ADSM'S  OF 
C  THE  SIHULATION  DATA  SET  THAT  HAVE  U0RK*N6  AND  INITIAL  VALUE 
C  ROUS.  IN  OTHER  UOR3S,  SOME  DL'S  (E.6.  OSV'S)  HAVE  THEIR 
C  INITIAL  VALUE?  STORED  IN  ROU  2.  PRIOR  TO  EACH  SIHULATION 

C  RUN,  THE  VALUES  ARE  COPIED  TO  ROU  1 .  ROU  1  IS  USED  DURIN6 

C  THE  SIHULATION  AND  HAT  IE  CHAH6ED. 


SUtROUTIr'E  IR0U2T ( IADSH) 

C— MODULE:  HOPADS  COHHON  USER  CODE 
C-- REFERENCE:  HOPADS  VOLUME  5.19 
C— PURPOSE: 

C  IROU2T  MILL  INITIALIZE  ALL  2  ROU  DATA  LISTS  IN  A  UORKIN6 
C  ADSfl.  SEE  IROUtT  FOR  FURTHER  DETAILS. 

C  IR0U2T  ALSO  INITIALIZES  THE  RESOURCE  DATA  LIST. 

C— INPUT/OUTPUT  PARAMETERS: 

C  IADSH(4)-DRAA  OF  THE  APSH  TO  INITIALIZE. 


SUBROUTINE  HODRF(NFN,NNODE) 

— MODULE:  HOPADS  COHHON  USER  CODE 
—REFERENCE:  HOPADS  VOLUME  3.19 
—PURPOSE: 

HODRF  IMPLEMENTS  THE  SAINT  MODERATOR  FUNCTIONS  FOR  HOPADS. 
THE  HODRF  CODES  ARE  NOT  RENUHIERED  FOR  EACH  SYSTEH  NODULE. 
IN  OTHER  UOROS,  OHLT  ONE  STREAN  OF  NODRF  CODES  IS  USED  FOR 
ALL  SYSTEH  NODULES. 

—  INPUT  PARAMETERS: 

HFH-HODRF  CODE 

CODE  1  IS  RESERVED  FOR  THE  HUMAN  FACTORS  MODERATOR 
FUNCTION  NODULE 
NNCDE-CURRENT  NODE  NuHDER 


SUBROUTINE  MOORFYINNODE) 

C--HOBULE:  HOPADS  COK.IOM  USER  COgF 
C — REFERENCE!  HOPADS  VOLUME  5.19 
C— PURPOSE  l 

C  HBBRFY  IMPLEMENTS  VIE  NOPASS  KODEfcATMS  FOR  TINE-TO-PERFORH 
C  OPERATOR  TASX  CLEMENTS  BY  iPLLIrf6  THE  APPROPRIATE  HUNAN 

C  FACTORS  NODULE  PR06RASS. 

C— INPUT  PARAMETERS! 

C  RHODE-CURRENT  N*»'£ 


SUBROUTINE  HXMSSY ( HSIB, NCOL , IUB , NCOL ) 

C-- MODULE!  NOPADS  COMMON  USER  CODE 
C — REFERENCE!  NOPADS  VOLUME  5.19 
C—PURPOSEi 

C  RXNS8Y  UILL  FIND  THE  HIGHEST  PRIORITY  MESSAGE  UHOSE  PRIORITY 
C  18  LESS  THAN  IUB.  THUS,  NXNSSY  CAN  BE  USED  TO  FIND  THE 

C  SECOND,  THIRD,  ETC.  MOST  IMPORTANT  HESSA6E. 

C— INPUT  PARAMETERS! 

C  HSIN5,MC0L>-ID'S  OF  MESSAGES 

C  IUD-UPPER  BOUND  ON  MESSAGE  PRIORITY.  ANY  MESSAGE  WITH 
C  PRIORITY  .IE.  IUB  HILL  BE  I8N0REB  IN  THE  SEARCH. 

C — OUTPUT  PARAMETERS! 

C  MCOL-COLUMN  NUMBER  IN  NSID  OF  THE  HIGHEST  PRIORITY  MESSAGE. 


SUBROUTINE  NEUTKY(NPTRK) 

C— MODULE*  HOPADS  COMMON  USER  CODE 
C—REFERENCEi  MOPABS  VOLUME  5.19 
C~  PURPOSE! 

C  NEUTKT  UILL  PUT  A  NEU  TRACK  EUTRY  INTO  EVERY  WORKING  ABSR'S 

C  TRACK  BATA  DL.  IF  THE  TRACK  IS  NOT  IN  RADAR  COVERAGE, 

c  Return  with  no  action. 

C— INPUT  PARAMETERS! 

C  NPTRK-COLUHN  IN  NTRACK  UHERE  THE  TRACK  IS  STORES 


SUBROUTINE  OEVALT <I»0P,NADSN,NC0PI,88,NNB, JTASK,IOPR,0SJ,TJ,*> 
C--MODULE!  NOPADS  COMMON  LSER  CODE 
C— REFERENCE!  HOPADS  VOLUME  5.19 
C-PURPOSli 

C  OEVALT  UILL  COMPUTE  THE  EXPECTED  GOAL  STATE  VECTOR  FOR  A 

C  PARTICULAR  OPTION  FOR  A  SPECIFID  OPERATOR 


C — INPUT  PARAMETERS!  \ 

C  IDOP-OPERATOR  II  : 

C  NADSM-SYSTEH  MODUL*  TYPE 

C  NCOPI-COPY  ROU  NUMBER 

C  fiStNNG) -CURRENT  GOAL  STATE  VECTOR 

C  ‘jTASK-OPERATOR  TASK  NUMBER  OF  THE  OPERATOR.  OEVALY  WILL 

C  EVALUATE  EXPECTED  60AL  STATES  6IVEN  THA'i  THE 

C  OPERATOR  PERFORMS  TASK  JTASK. 

C— -INPUT/OUTPUT  PARAMETERS: 

C  I0PR(2)-BIAA  OF  THE  OPERATOR 

C— OUTPUT  PARAMETERS: 

C  6SJ(NN6) -EXPECTED  GOAL  STATES  RESULTING  FROM  PERF0RHIN6 

C  TASK  JTASK 

C  TJ-EXPECTEB  TIME  (MINUTES)  TO  PERFORM  TASK  JTASK.  IF  THE 

C  OPERATOR  CANNOT  PERFORM  OR  DOES  NOT  PERFORM  TASK  JTASK, 

C  THEN  TJ—  1. 

C— ALTERNATE  RETURNS! 

C  1 -JTASK  IS  GREATER  THAN  THE  MAXIMUM  TASK  HUMBER  THAT  THE  OPERATOR 
C  PERFORMS.  9EVALY  WILL  IE  CALLED  REPEATEDLY  UITH  6REATER 

C  VALUES  OF  JTASK  UNTIL  THIS  CONDITION  OCCURS. 


SUBROUTINE  OPREY(IOPP) 

C 

C— MODULE!  MOPADS  COMMON  USER  CODE 
C— REFERENCE!  MOPADS  VOLUME  $.19 

Ol  CMPURPQSEi  ERROR  CHECKING  TO  ASSURE  THAT  NON-OPERATORS  ARE 

CM  NOT  PROCESSED  AS  OPERATORS 

C 

CMINPUT  PARAMETER!  IOPP  -  ENTITY  ID 
C 


FUNCTION  PRIOR(ITASK) 

C— MODULE!  MOPADS  COMMON  USER  CODE 
C— REFERENCE!  MOPADS  VOLUME  5.19 
C~ PURPOSE! 

C  PRIOR  IS  URITTEN  TO  SATISFY  CALLS  BY  SAINT.  IT  IS  NOT 
C  USED  BY  MOPADS.  THIS  FUNCTION  IS  A  DUMMY. 

C— INPUT  PARAMETERS! 

C  1TASK-TASK  NODE  NUMBER 
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SUBROUTINE  PSHNTKIOPT, ISOP ,TSKNEU,LE*> 

C 

C— MODULE:  HOP  ADS  COHHON  USER  COD”. 

C— REFERENCE:  HOPADS  VOLUHE  5.19 

CMPURPOSEl  THIS  SUBROUTINE  IS  US*I  TC  REMOVE  (.'’OP,  THE  CURRENT  TASK 
C  FROM  THE  OPERATOR  TASK  STACK. IT  THEN  FLACES  A  SET  OF 

C  TASKS  TO  IE  PERFORMED  UNTO  THE  TASK  STACK. THE  TASKS  OR 

C  THE  TASK  STACK  HILL  IE  PERFORMED  ACCQSDIN6  TO  THE  UFO 

C  SERVING  DISCIPLINE. 

C 

C** INPUT  PARAMETERS:  I0P7-0PTI0N  TO  CLEAR  THE  OPERATORS  HEHORT 
C  (1 -CLEAR  MEMORY ,0-10  NOT  CLEAR  MEMORY) 

C  HOP-OPERATOR  II 

C  T8KNEU(5,LEM)-ARRAY  CONTAINING  TASK  DATA 

C  LEN-NUMIER  OF  TASKS  TO  All  TO  TASK  STACK 

C 


FUNCTION  PSY(PSCNfTF) 

C— MODULE:  HOPADS  CONNOR  USER  CODE 
C— REFERENCE:  HOPADS  VOLUHE  5.19 
C— PURPOSE: 

C  rsr  MILL  COMPUTE  THE  SUCCESS  PROBAI2L2TY  FOR  A  TASK  OR 
C  A  TASK  ELEMENT. 

C— INPUT  PARAMETERS: 

C  PSCN-NONINAL  PROBABILITY  OF  SUCCESS 

C  TF-OPERATOR'S  TASK  ERROR  FACTOR  OR  TASK  ELELMENT  ERROR 

C  FACTOR 

C—METHOI 

C  LET  DELTA- (1-PSCN)*TF 

C  THEN  PST-MAX(.1fPSCN«DELT) 

C 


SU1R0UTINE  RNBTHTCOL, IDOP, RANGE, ITN) 

C— MODULE:  HOPADS  COHHON  USER  CODE 
C— REFERENCE:  HOPAIS  VOLUHE  5.19 
C— PURPOSE: 

C  RN6Y  HILL  DETERMINE  IF  A  SPECIFIED  TRACK  IS  VISIBLE  TO  AN 
C  OPERATOR,  IN  OTHER  WORDS  IT  WILL  CHECK  IF  IT  IS  WITHIN 

C  HIS  SCREEN  RAPSE.  RNBT  DOES  NOT  CHECK  TO  SEE  IF  THE 

C  TRACK  IN  ALSO  VISIBLE  TO  A  VIEWER. 


C — INPUT  PARAMETERS! 

C  NTCOL-THE  COLUMN  NUMBER  OF  THE  TRACK  IN  NTRACK 
C  IDOP-IHE  OPERATOR'S  ID 

C  RANGE-THE  SCREEN  RANGE  OF  THE  OPERATOR 

C-- OUTPUT  PARAMETERS! 

C  ITN-TES/NO 

C  1-YES,  THE  OPERATOR  CAN  SEE  THE  TRACK 

C  2-NO,  HE  CAN'T 


SUBROUTINE  SHELLY (M, BATA, NDEX) 

C— MODULE!  HOPADS  COMMON  USER  CODE 
C— REFERENCE!  MOPADS  VOLUME  S.19 
C— PURPOSE! 

C  SHELLY  HILL  SORT  DATA  LARGEST  TO  SMALLEST  UITH  A  SHELL  SORT. 
C  DATA  IS  NOT  ACTUALLY  DISTURBED.  NDEX  IS  MADE  INTO  A  CROSS 

C  REFERENCE  TO  DATA  IN  THE  CORRECT  SORTED  ORDER. 

C— INPUT  PARAMETERS! 

C  N-LEN6TH  Or  DATA  AND  NDEX 

C  ilATA(N)-ARRAY  TO  BE  SORTED 

C— OUTPUT  PARAMETERS! 

C  MBEX'NI-INDEX  ARRAY  TO  DATA.  ON  OUTPUT  THE  1-TH  LARGEST 
C  ELEMENT  OF  BA  In  VILl  BE  DATA < NDEX < 1 ) > 


SUBROUTINE  SHS6Y(HR0UL,NPEC,N0PR,IDIST,NVAR,MSN0) 

C 

C— MODULE!  MOPADS  COMMON  USER  CODE 
C— REFERENCE!  MOPADS  VOLUME  5.19 
C 

CMPURPOSEi  TO  HANDLE  SENDING  OF  ALL  MESSAGES  FROM  USER  CODE.  ALSO 
C*«  STORES  IN  A  LOCAL  ARRAY  ALL  STATIC  MESSAGE  CHARACTERISTICS. 

C«*  THIS  ARRAY,  NNMS6,  MUST  BE  CHANGED  IF  ANY  OF  THESE 

cm  nESSASE  CHARACERIST ICS  ARE  CHANGED  BY  AN  ANALYST  OR  IF 

CM  ANT  NEU  MESSAGES  ARE  ADDED. 


CMIMPUT  PARAHETERSi  HROVL  -  HESSA6E  RCU  NUMBER  (R3U  IN  NNHSS) 

C  NREC  -  RECEIVER  COPY  ROU  NUMBER 

C  NOPR  -  RECEIVER  OPERATOR  TYPE  (UNUSED  IF  COLUMN 


C 

C 

C 

C 

c 

c 

c 


1  OF  NNMSG  IN  ROU  MROUL  IS  NOT  0) 

1 9 1ST  -  MESSAGE  DISTRIBUTION  CODE  (FOR  CODE 
DEFINITIONS  SEE  SUBROUTINE  SNDHSA) 

NVAR  -  ARRAY  OF  LENGTH  3  CONTAINING  THE  VARIABLE 
MESSA6E.  COLUMNS  11-13  IN  NNMSG  CONTAIN 
THE  CODES  DEFINING  THE  VARIABLE  MESSAGE. 
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£«*OUTPUT  PARAMETERS:  HSMO 


THE  MESSAGE  SES  NJHBER  ASSIOKEj  TO  THE  «SS 
BY  SUBROUTINE  SNCMSA 


C**L0CAl 

C 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 


VARIABLES:  NNHS6(50,15>  -  THIS  ARRAY  CONTAINS  STATIC 

INFORKATIJK  FOR  EACH  MESSAGE  TYPE. 
EACH  FUNCnQWAL  TYPE  -  S'QTYrE 
COMBINATION  HAS  A  ROM  IK  THE  ARRAY. 
THE  MESSAGE  R3V  MUMPER  THEM  PEFERS 
TO  A  UNI UUE  MESSAGE  TYPE  ANB  '‘IVES 
THE  ROU  COHTAIK1KJ  INFO  FOR  THAT 
MESSAGE.  COLUMN  DEFINITIONS  ARE 
GIVEN  BELOU. 

COLUMN  DEFINITIONS  FOR  THE  NNHSG  ARRAY 


RECEIVER  OPERATOR  TYPE  CO  IF  MUST  BE  CALCULATES) 
FUNCTIONAL  TYPE 
MESSAGE  SUBTYPE 
HESSA6E  PRIORITY 

COMMUNICATION  NETUORK  (1-VOICE,  2-ATDL) 

ACKNOWLEDGMENT  REQUIRES  (1-YES,  2-MO) 

AT3L  CODE  (UNUSEB) 

UNUSED 
■  UNUSEB 

0  -  NO.  OF  UORBS  IN  THE  VARIABLE  MES3A6E  (NOT  C0UNTIN8  IT 
11-13  -  VARIABLE  MESSAGE  TYPE  CODES  (FOR  NVAR  UORBS  1-3> 
(THESE  COSES  ARE  USES  TO  CHECK  THE  VALUES  OF 
NVAR  TO  ASSURE  THAT  LEGAL  VALUES  HERE  PASSES  IN. 
THE  CODES  ARE  DEFINED  BELOU  UITH  LE6AL  VALUES 
SHOWN  IN  PARENTHESES) 


CODES  FOR  NNHSG  COLUMNS  11-13 


1  -  UHICH  FIRE  SECTION  (0-EITHER,1-A,2-B,3-B0TH) 

2  -  TRACK  COLUMN  POINTER  d  TO  NCOLS) 

3  -  NESSA6E  NUMBER  ACKNUVLED6INB  (1  TO  LASTH) 

4  -  FU  EFFECTIVE  STATU3  (1-KILL, 2-NO  KILL) 

5  -  IHIPIR  STATUS  (1-LOCK, 2-NO  LOCK) 

6  -  RAID  SIZE  (1-ONE, 1-FEU, 3-NANY) 

7  •  IH1PI3  LOCKING  METHOD  (1-MANUAL, 2-AUTO) 

G  -  METHOD  OF  FIRE  d-SHOOT-LOOK-SHOOT, 2-RIPPLE  FIRE) 

14  -  TASK  NODE  NUMBER  SENT  FROM  (0  IF  VARIABLE,  BECAUSE 

THIS  INFORMATION  IS  NOT  REALLY  NEEDED  TO  SEND  THE 
MESSAGE) 

15  -  USAGE  STATUS  >1  HESSA6E  CURRENTLY  BEING  USED  BY  AT  LE 

ONE  SYSTEM  MODULE 
•1  HESSA6E  NOT  BEING  USED 
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S-Jt XCUTINE  STATE 

C — HODUL li  H0PA3S  COMMON  USER  CODE 
C— REFERENCE!  MOPADS  VOLUME  3.19 
C 

CMPURPOSEi  THIS  IS  SUBROUTINE  STATE  FOR  THE  MOPADS  HSAIMT  SG'fKAWE. 

C  IT  IS  1!  TEC  TO  UPDATE  THE  POSITIONS  OF  THE  AIRC5AF  f  i«  THE 

C  AIR  SCENARIO. 


SUBROUTINE  STDBY(NRUN) 

C— MODULE:  MOPADS  COMMON  USER  CJDE 
C-REFERENCEj  MOP  DS  VOLUME  3.19 
C— PURPOSE! 

C  STDBV  HILL  DUMP  COUNTER  STATISTICS  ..  .HE  MOPADS  TATA  BASE 
C  AFTER  A  RUN.  STDBY  DOES  NOT  RE-INI7/.ALIZE  THE  COUNTER 
C  STATISTICS  ARRAYS  AFTER  A  DUMP. 

P — INPUT  PARAMETERS! 

C  HRUN-RUN  NUMBER  JUST  COMPLETED 


SUBROUTINE  THR1 YlIPOP,NCQPI,KTRK,XLB,TQA,KPTRK,IST> 

C — MODULE!  MOPADS  COMMON  USER  CODE 
C— REFERENCE!  MOPADS  VOLUME  5.19 
C—PURPOSE! 

C 

C  THR1Y  WILL  LOCATE  THE  TRACK  THAT  IS  MOST  THREATENING  TO  AN 
C  AIR  DEFENSE  COMPONENT.  THIS  SUBPROGRAM  15  USED  TO  EVALUATE 

C  THE  SELF  DEFENSE  60AL.  TKR1Y  UILL  ALSO  EVALUATE 

C  A  SINGLE  TRACK  BASED  ON  THE  VALUE  OF  KTRK. 

C— INPUT  PARAMETERS! 

C  IDOP-THE  OPERATOR  ID 

C  MCOPI-COPY  ROU  NUMBER  OF  THE  COMPONENT 

C  KTRK-TRACK  COLUMN  NUMBER  IN  NTRACK 
C  (DEVALUATE  ALL  TRACKS 

C  K-EVALUATE  TRACK  K  ONLY 

C  XLB-LOUER  BOUND  ON  TOA.  THE  TRACK  UITH  THE  MINIMUM  TIME 
C  OF  ARRIVAL  BUT  GREATER  THAN  XLD  UILL  BE  RETURNED.  XLI.GT.0 

C  IS  USED  TO  EXCLUDE  THE  MOST  THREATENING  TRACK  UHEN 

C  ESTIMATING  THE  IMPACT  ON  GOALS  OF  ASSIGNING  THE  HOST 

C  THREATENIN6  TRACK  TO  AN  FU. 
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C — PUTPUT  PARAMETERS » 

C  TOA-TIHE  OF  ARRIVAL  OF  THE  HOST  THREATENING  TRACK  . 

C  KPTRK-NTRACK  COLUMN  OF  THE  HOST  THREATENING  TRACK 

C  IET-TRACK  GTATUS(0-H0  TRACK, 1 -UNIDENTIFIED r2-2BtNTIFiEP  AS  MG SI IL 
C  OR  UNKNOWN, 3' 2NDARY  ASSIGNED) 


SUIROUTINE  THR2 Y ( IDOP , NCOPI , KTRK • XLB , TOA, KP7RK , 1ST) 

C— MODULE:  HOPADS  COMMON  USER  CODE 
C— REFERENCES  HOPADS  VOLUME  5.19 
C— PURPOSES 
C 

C  THR2Y  U1LL  LOCATE  THE  TRACK  THAT  IS  MOST  THREATENING  TO  AN 
C  AIR  DEFENSE  COMPONENT'S  PROTECTED  SITES.  .'HIS  SUBPROGRAM  IS 
C  USED  TO  EVALUATE  THE  GOAL  OF  PROTECTING  CRITICAL  ASSETS. 

C  THR2Y  UILL  ALSO  EVALUATE  ONLY  ONE  TRACK  BASED  CN  THE 

C  VALUE  OF  KTRK. 

C— INPUT  PARAMETERS  s 
C  IDOP-THE  OPERATOR  II 

C  NCOPI-COPY  ROU  NUMBER  OF  THE  COMPONENT 

C  KTRK-TRACK  COLUMN  NUMBER  IN  NTRACK 

C  O-EVALUATE  ALL  TRACKS 

C  K-EVALUATE  TRACK  K  ONLY 

C  XLI-LOUER  BOUND  ON  TOA.  tHE  TRACK  U1 TH  THE  NINIHUN  TINE 
C  OF  ARRIVAL  BUT  GREATER  THAN  XLi  UILL  BE  RETURNED.  XLB.BT.O 

C  IS  USED  TO  EXCLUDE  THE  HOST  THREATENING  TRACK  UHEN 

C  ESTIMATING  THE  IMPACT  ON  GOALS  OF  ASSIGNING  THE  HOST 

C  THREATENING  TRACK  TO  AN  FU. 

C— OUTPUT  PARAHETERSs 

C  TOA-TIME  OF  ARRIVAL  OF  THE  HOST  THREATENING  TRACK 

C  KPTRK-NTRACK  COLUMN  OF  THE  HOST  THREATENING  TRACK 

C  IST-TRACK  STATUS ( 0-N0  TRACK, 1 -UNIDENTIFIED, 2-IDENTIF1ED  AS  KOSTIL 
C  OR  UNKN0UN,3-2NDARY  ASSIGNED) 


SUBROUTINE  TOAYtPOS, NTR,ETA) 

C— MODULE:  HOPADS  BATA  BASE  APPLICATION  PROGRAMS 
C— REFERENCE!  HOPADS  VOLUME  5.1B 
C— PURPOSE! 

C  GIVEN  A  POINT  AND  A  TRACK,  TOAY  UILL  COMPUTE  THE  GROUND 
C  DISTANCE  BETWEEN  THEM  AND  THE  TINE  TILL  THE  AIRCRAFT 
C  ARRIVES  AT  THE  POINT  IF  IT  TURNS  IMMEDIATELY  TOWARD  IT 

C  (USING  THE  AIRCRAFT'S  CURRENT  SPEED).  IF  THE  AIRCRAFT  IS 

C  OUTBOUND,  AN  INFINITE  TINE  WILL  BE  RETURNED. 

C— INPUT  PARAMETERS! 

C  P0S(3)-X,Y,Z  OF  THE  POINT  (Z-FEET,  X  AND  Y-N.KI.) 

C  NTR-COLUNN  IN  NTRACK  OF  THE  TRACK 


C — OUTPUT  PARAMETERS* 

C  ETA(2)”(1)*TIRE  TILL  ARRIVAL.  IF  THE  CURRENT  HEADING  OF  THE 
C  TRACK  IN  OUTBOUND  FROM  THE  POINT.  THEN  ETA<1)« 

C  t.EIO. 

C  <2>«6R0U«0  DISTANCE (N .HI . )  FROM  THE  POINT  TO  THE 

C  TRACK. 


SUBROUTINE  TOTY1IDOP) 

C— MODULE!  HOPADS  COHHON  USER  CODE 
C — REFERENCE!  HOPADS  VOLUHE  5.19 
C— PURPOSE* 

C  TOTY  UILL  COHPUTE  THE  TIHE-QN-TASK  FOR  AN  OPERATOR  AND  UPDATfc 
C  HIS  OSV.  TOTY  IS  COHPUTED  AS  <TN0U-TSTRTK>/60*(THE  INITIAL 
C  VALUE  OF  TIHE  ON  TASK)  I 

C— INPUT  PARAHETERS* 

C  IDOP-THE  OPERATOR'S  ID  I  . 


SUBROUTINE  TSEQY ( IDOP,NXTAS,KASE) 

C — NODULE*  HOPADS  COHHON  USER  CODE 
C— REFERENCE*  HOPADS  VOLUHE  5.19 
C— PURPOSE* 

C  TSEQY  UILL  SELECT  THE  NEXT  TASK  FOR  AN  OPERATOR.  IT  IS 

C  CALLED  TO  INITIATE  THE  TASK  SEQUENCING  PROCEDURE. 

C— INPUT  PARAHETERS* 

C  IDOP-OPERATOR  ID 

C— OUTPUT  PARAHETERS* 

C  NXTAS-NUHBER  OF  THE  NEXT  OPERATOR  TASK  TO  PERFORM.  IF  NO 
C  TASK  UILL  REDUCE  THE  OPERATOR'S  OBJECTIVE  FUNCTION, 

C  NXTAS’O 

C  KASE-OUTPUT  CONDITION 

C  1-NXTAS  IS  THE  NEXT  TASK  ON  THE  STACK. 

C  2-HXTAS  IS  NOT  FROH  THE!  SfACK.  THE  CALLING  PROGRAM 

C  NEEDS  TO  LOAD  THE  STACK  UITH  APPROPRIATE  TASK 

C  NIIHBER(S) . 


SUBROUTINE  UACCPT 

C — MODULE s  HOPADS  COHHON  USER  CODE 
C — REFERENCE*  HOPADS  VOLUHE  5.19 
C — PURPOSE* 

C  UACCPT  IS  NOT  USED  BY  HOPADS.  THIS  PROGRAH  IS  A 
C  DUHfiY  TO  SATISFY  SAINT  EXTERNAL  REFERENCES. 
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o  o  o  n  o  o  n  i  n  i  r. 


SUBROUTINE  l'ERR(KODE) 

c— KODUUj  KSPPJs  common  user  code 
<:j>  L— ‘PEFEREKCF t  MOPADS  VOLUME  5.1? 

C-PURPOEEl 

C  UEitR  UIU.  PERFORM  ADDITIONAL  NOPASS  ERROR  PPP»  ESSIMG  ON 
A  SYSTEM  NODULE  SPECIFIC  BASIS. 

-IriPUT  PARAMETERS! 

NODE-ERROR  CODE  6ENERATED  FROM  SYSTEM  MODULE  SOFTWARE 


SUBROUTINE  UINPT 

— MODULE!  MOPADS  COMMON  USER  CODE 
—REFERENCE!  MOPADS  VOLUME  5.19 
—PURPOSE! 

UINPT  IS  CALLED  ONCE  PRIOR  TO  THE  START  CF  A  MOPADS 
SIMULATION  TO  COMPLETE  IOTTMIUAU  i’i  MOPADS  ARRAYS 
AND  THE  DATA  BASE. 


SUBROUTINE  USCOH1M  ifiON) 

C— MODULE!  MOPADS  COMMON  USER  CODE 
C — RFt’f  RENCE:  MOPADS  VOLUME  5.1? 

C- -PL’RPOSE  t 

C  USCQNB  IS  NOT  USED  BY  MOPADS.  THIS  PROGRAM  IS  A  DUMMY 
(f  C  TO  SATISFY  SAINT  EXTERNAL  RFFT  '  '•  LS. 


FUHCTT  USERF(ICODE) 

C . MODULE:  M0PAJ3  COMMON  USER  CODE 

C— REFERENCE:  MOPADS  VOLUME  5.1? 

C— PURPOSE: 

C  !  EVALUATES  the  MOPADS  U'"  H  USER  FUNCTIONS 
C  — INPUT  PAT-:  VI PIERS: 

C  ICODE-USE.R  FLi?ru  m  . 

C — OUTPUT  PARAMETERS ! 

C  USERF-VALUE  OF  1  HE  USIK  FUNCTION 
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FUNCTION  USERI NCICODE) 

C— NODULE:  HOPADS  COMMON  USER  CODE 
C--REFERENCE:  NOPADS  VOLUME  5.1? 

C— PURPOSE: 

C  USERIN  EVALUATES  THE  NOPADS  INPUT  USER  FUNCTIONS 
C— INPUT  PARAMETERS: 

C  ICODE-USER  FUNCTION  CODE 

C— OUTPUT  PARAMETERS: 

C  USERIN-VALUE  OF  THE  USER  FUNCTION 


SUBROUTINE  USTART(NRUN) 

C— MODULE:  HOPADS  CONTROL  SYSTEM  NODULE 
C~ REFERENCE:  NOPADS  VOLUME  5.19 
C-PURPOSEi 

C  USTART  IS  CALLED  AT  THE  START  OF  EACH  SIMULATION  RUN  BY 
C  NSAINT  TO  PERFORM  ANY  INITIALIZATION  NEEDED. 

C — INPUT  PARAMETERS: 

C  NRUN-RUN  NUMBER  ABOUT  TO  BES1N. 


SUBROUTINE  UTASK(NT,NPLACE) 

C — NODULE:  NOPAuS  COMMON  USER  CODE 
C--REFERENCE:  MOPADS  VOLUME  5.19 
C 
C 

C**PURPQSE:  TO  BE  THE  MASTER  PROCESSOR  OF  USER  CODE  FOR  ALL 
Cm  SYSTEM  MODULES.  CALLS  A  ROUTINE  FOR  EACH  SYSTEM 

CM  MODULE,  WHICH  CALLS  TASK  NODE-SPECIFIC  ROUTINES 

CM  FOR  ALL  TASKS  REQUIRING  UNIQUE  PROCESSING. 


C 

CMINPUT 

CM 

CM 

Cm 

Cm 

Cm 

Cm 

Cm 

CM 

CM 

CM 

c 


PARAMETERS:  NT  -  TASK  NUMBER 

NPLACE  -  TASK  OCCURANCE  TIME 

«  1  FIRST  PREDECESSOR  COMPLETION 

(ONLY  IF  DIFFERENT  FROM  THE  RELEASE 
TIME.  THIS  NORMALLY  WON'T  BE  THE  CASE) 

*  2  RELEASE  TIME 

=  3  START  TIME  (SAME  AS  RELEASE  TIME  IF 
THE  TASK  REQUIRES  NO  RESOURCES) 

■  A  COMPLETION  TIME 

*  5  CLEARING  TIME  (  A  TASK  CANNOT  BE 

BOTH  COMPLETED  AND  CLEARED) 
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SUBROUTINE  UNTIDY  (NE6NUH) 


C 

C—HOCU;Ej  r.HPADS  CONHON  USER  code 
C— REFET.EKCtt  NOPADS  VOLUME  5.1? 

C**PURPPSCl  THIS  SUBROUTINE  IS  USED  TO  ASSIGN  OPERATOR  ID  NUMBERS  TO 
C  CONTOL  ENTITIES  CREATED  DURING  THE  SIMULATION. 

C 

C«*3UTPUT  PARAMETERS:  NESNUM»NEGATIVE  OPERATOR  ID  REPRESENTING  THE 
C  CONTROL  ENTITY 

C 
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6-0  USER  IHSTRUCTIOHS 

The  subprograms  In  the  CSMP  fall  into  several  fp-oupings 
based  on  their  flections: 

1.  Track  Processing. 


CHLTY 

changes  elements  of  the  Track 
Data  data  list  in  the  data  hue 

CVTKY 

- 

checks  if  an  air  defense  unit 
▼levers  can  see  a  track 

DEI  THY 

- 

deletes  a  trade  from  all  Track 
Data  data  lists 

5EWTRY 

- 

inserts  a  new  track  into  ell 
Track  Data  data  lists 

RHGY 

- 

determines  if  a  track  is  visible 
to  an  operator 

FLTY 

- 

computes  missile  flight  time 

2.  Task  Sequencing. 

GEVAI.Y 
GPRIY 
HXMSGY 

OEVALY 

THR1Y,THR2Y 
TOAY 
TSEQY 

3.  Statistics. 

CCOBSY  -  narks  time  for  M0PAU6  Operator 

Task  Fraction  Statistics. 


evaluates  an  operator's  goals 

evaluates  goal  priority  functions 

finds  an  operator's  highest 
priority  outstanding  messages 

computes  expected  goal  states 
for  various  operator  tasks 

locates  high  threat  tracks 

computes  a  track’s  threat 

selects  next  task  for  an  operator 


CSTATY 


records  observations  of  count 
statistics 


pi 


?: 

v* 

* 

V 


V, 

V.* 


£ 


> 

v 


ECT£.r 


drops  count  statistics  to  the 
data  base 


1*. 


Initialization. 

BLOCEf 


QSOURT 

mn.IBOWlI, 

XR0V2T 


block  data 

find  source  node  for  an  operator 
initialization  of  arrays 


5.  Operator  Processing. 


CLMEMT 

- 

dear  an  operator's  memory 

MODHTT 

- 

human  factors  moderator  function 

access 

P8HHTT 

J 

i 

i 

manage  an  operator's  memory  stack 

PST 

1 

; 

1 

compute  success  probability  for 

a  task 

SMSGT 

- 

send  messages 

Ton 

- 

compute  operator's  time-on-task 

6.*  M3AIBT  User  Called  Programs. 

DTOIT,-  EfTLC.-  .  -  see  Walker  (1983)  for  details 
M0DR7,  PRIOR, 

STATS,  UACCFT, 

uerr,  ourpr, 

I;  I  US  CORD,  TJBEHP, 

USERU,  (JOT ART, 
and  UTASI 


7.  Mis  cellaneous . 


COMET 

- 

error  processing 

oPRrr 

• 

error  checking 

SHZLLT 

mm 

perform  s  shell  sort  oo  an  array 

V3TIDT 

- 

assign  an  ID  to  a  control  entity 
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7-0  ERROR  PROCESSING 


When  Appropriate,  CSKP  programs  use  the  DBAP  error  processing, 
ERRORA,  for  error  processing-  At  other  times,  the  st radar d  MSAINT 
program  SERR  is  used.  Error  codes  7000  to  7999  have  been  reserved 
for  use  by  the  SMCP.  Defined  codes  are  as  follows: 


Error  Code  _ Error  Conditions 

7000  Invalid  System  Module  Type 

7001  Invalid  Copy  Row  Number 

7002  Invalid  Count  Statistics  Index 

7003  Screen  range  evaluation  requested 

for  an  operator  for  whom  that 
information  is  not  defined 

TOOU  Action  requested  for  an  operator 

in  an  inactive  unit 

7005  ITRID/NTRID2  arrays  full 

7006  K33TE  array  full 

7007  NFSTOR  full 

7008  A  system  module  type  that  cannot  be 
classified  as  a  fire  unit  or  a  non¬ 
fire  unit  has  been  encountered 

7009  NEB  AD  array  full 

7010  too  many  operators 

7011  too  many  operators  in  one  system 
module 

7012  local  array  IDATA  must  be  increased 
to  MNRW 

7013  too  many  protected  sites  for  XHAWK 

70lU  too  many  display  parameters 

7015  Invalid  System  Module  type 


RNGT 


NFST3A.NC0PYA, 

1CFST2A 


1TFST3A, NCOFYA, 
HFST2A 


NCOFYA 

INITY.NCOPYA, 

NFST3A,THR2Y 

NCOFYA ,NFST2A 
N COPY A 
NCOPYA 

NFST2A 

NFST2A 

DUTY 

GEVALY.OEVALY 
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7016 

7017 


Attempt  xo  evaluate  operator  goal* 


GZVALY.OEVALY 

GPRIT 


Variable  HHG  in  greater  than  the 
number  of  operator  goals 

7018  JTASK.IE.O  OEV'ALY 

7015  Invalid  moderator  function  code  MODRF 

7020  Incorrect  distribution  type  for  MODRFY 

moderator  function 

7021  Invalid  skill  number  MODRFY 

7201  Invalid  message  row  number  SMSGY 

7202  Illegal  receiver  copy  row  number  SMSGY 

7203  Illegal  receiver  operator  ID  SMSGY 

720U  Illegal  variable  message  value  SMSGY 

7205  Non-operator  passed  as  operator  various 

7207  Attempt  to  send  an  inactive  message  SMSGY 

7208  Skill  weights  do  not  sum  to  1.0  or  100  MODRFY 

8-0  COMMON  VARIABLE  DEFINITIONS 


Two  labeled  COMMON  areas  are  used  by  the  CSMP.  /C0M1Y/  con¬ 
tains  numeric  data  and  /C0M2Y/  contains  CHARACTER  data.  In  addition, 
certain  FORTRAN  77  PARAMETER’S  are  used  with  these  COMMON  areas. 


Variable 

Definition 

Value 

C0W0N 

MTASKY 

Maximum  number  of  operator 
tasks  for  any  operator 

U0 

paramet! 

MXSTAY 

Maximum  number  of  count 
statistics  for  any  system 
module 

50 

PARAMETI 

CLABY 
( MXSTAY, U) 

*  25 

Labels  of  count  statistics  CLABY 
(I,J)  is  the  label  of  statistic 

I  for  systan  module  type  J 

- 

/C0M2Y/ 

COUNT 

(MXSTAY, 

30) 

Storage  for  count  statistics 
C0UNTY(I,J)  -  count  for  statistic 
I,  copy  J 

- 

/C0M1Y/ 
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urn 

Maximum  tine  between  general 
viewer  updates  of  tracks 

0.2$ 

/00KLX/ 

MAIMS! 

MsTlTmrm  rov  dimension  of  arrsy 
SKMSG  In  SUBR017TIHE  SMS  GY 

3** 

/coal/ 

MAXOPT 

Maximus  operator  type 

9 

/com!/ 

MXSTY(U) 

Humber  of  count  statistics 
defined  for  each  system 
module  type 

/C0M1I/ 

TASEf(l50, 

mm) 

TASKY(I,J)  is  the  cumulative 
time  operator  I  spends  doing 
tsak  J 

m 

/00M1Y/ 

TTm(30) 

End  time  for  each  copy  to  compute 
task  fraction  statistics.  Usually 
end  of  run  time,  but  msy  be 
earlier  if  the  unit  vas  destroyed 
by  enemy  action 

/COKLY/ 

tvwhy 

Time  of  the  next  general  viewer 
update  of  tracks 

/C0M1Y/ 

I 
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MOPADS  Terminology 


AIR  DEFENSE  SYSTEM  A  component  of  Air  Defense  whicJ*  Includes 

equipment  and  operators  and  i  or  which 
technical  and  tactical,  training  sre  required. 
Examples  are  ELAVK  and  the  AH/TSQ-73* 


AIR  DEFENSE  SYSTEM 
MODULE  (ADSK) 


AIR  SCENARIO 


Models  of  operator  actions  and  equipment 
characteristics  for  Air  Defense  Systems  in 
the  MOPADS  software.  These  models  are  pre¬ 
pared  with  the  SAINT  simulation  language. 
Air  Defense  System  Modules  include  the 
SAINT  model  and  all  data  needed  to  com¬ 
pletely  define  task  element  times,  task 
sequencing  requirements,  and  hu^aan  factors 
influences. 


A  spatial  and  temporal  record  of  aerial 
activities  and  characteristics  of  an  air 
defense  battle.  The  Air  Scenario  includes 
aircraft  tracks,  safe  corridors,  ECM,  and 
other  aircraft  and  airspace  data.  See 
also  Tactical  Scenario. 


BRANCHING  A  term  used  in  the  SAINT  simulation  lang¬ 

uage  to  mean  the  process  hy  which  TASK  nodes 
are  sequenced.  At  the  completion  of  the 
simulated  activity  at  a  TASK  nodfe,  the 
Branching  from  that  node  determines  which 
TASK  nodes  will  be  simulated  next. 


DATA  BASE  CONTROL  That  -art  of  the  MOPADS  software  which 

SYSTEM  performs  all  direct  communication  with  the 

MOPADS  Data  Base.  All  information  transfer 
to  and  from  the  data  base  is  performed  by 
invoking  the  subprograms  which  make  up  the 
Data  Base  Control  System. 


DATA  SOURCE  A  specialist  in  obtaining  and  interpreting 

SPECIALIST  Army  documentation  and  other  data  needed  to 

prepare  Air  Defense  System  Modules. 


ENVIRONMENTAL 
STATE  VARIABLE 


An  dement  of  an  Environmental  State 
Vector. 


ENVIRONMENTAL 

STATE  VECTOR 

An  array  of  values  representing  conditions 
or  characteristics  that  may  affect  more 
than  one  operator.  Elements  of  Environmen- 
tal  State  Vectors  may  change  dynamically 
during  a  MOPADS  simulation  to  represent 
changes  in  the  environment  conditions. 

'moderator  FUNCTION 

A  mathematical/logical  relationship  vhich 
dters  the  nominal  time  to  perform  an  opera¬ 
tor  activity  (usually  a  Task  Element).  The 
nominal  time  ia  changed  to  represent  the 
operator's  capability  to  perform  the 
activity  based  on  the  Operator's  State 
Vector. 

MOPADS  DATA  BASE 

A  computerized  data  base  designed  specifi¬ 
cally  to  support  the  MOPADS  software.  The 
MOPADS  Data  Base  contains  Simulation  Data 
Set(s).  It  conrmmicates  interactively  with 
MOPADS  Users  during  pre-  and  post-run  data 
specification  and  dynamically  with  the  SAHIT 
software  during  simulation. 

KOPADS  MODELER 

An  analyst  who  will  develop  Air  Deiense 
System  Modules  and  modify/develop  the 

MOPADS  software  system. 

MOPADS  USER 

An  analyst  who  will  design  and  conduct  simu¬ 
lation  experiments  with  the  KOPADS  software. 

MSAINT 

(MOPADS/SAINT) 

The  variant  of  SAINT  used  in  the  MOPADS 
system.  The  standard  version  of  SAINT  has 
been  modified  for  MOPADS  to  permit  share¬ 
able  subnetworks  and  more  sophisticated 
interrupts.  The  terms  SAINT  and  MSAINT  are 
used  interchangeably  when  no  confusion  will 
result.  See  also,  SAINT. 

OPERATOR  STATE 
VARIABLE 

One  element  of  an  Operator  State  Vector. 

OPERATOR  STATE 

VECTOR 

An  array  of  values  representing  the  condi¬ 
tion  and  characteristics  of  an  operator  of 
an  Air  Defense  System.  Many  values  of  the 
Operator  State  Vector  will  change  dynamically 
during  the  course  of  a  MOPADS  simulation  to 
represent  changes  in  operator  condition. 

OPERATOR  TASK 

An  operator  activity  identified  during 
weapons  system  front-end  analyses. 

SAINT 

The  underlying  computer  simulation  language 
used  to  n^-del  Air  Defense  Systems  in  Air 
Defense  System  Modules.  SAINT  is  an  acronym 
fnr  Systems  Analysis  of  Integrated  Networks 
of  Tasks.  It  is  a  well  documented  language 
designed  specifically  to  represent  human 
factors  aspects  of  man/machine  systems. 

See  also  MSAH3T. 

SIMULATION  DATA  SET 

The  Tactical  Scenario  plus  all  required 
simulation  initialization  and  other  experi¬ 
mental  data  needed  to  perform  a  MOPADS 
simulation. 

SIMULATION  STATE 

At  any  instant  in  time  of  a  MOPADS  simula¬ 
tion  the  Simulation  State  is  the  set  of 
values  of  all  variables  in  the  MOPADS  soft¬ 
ware  and  the  MOPADS  Data  Base. 

SYSTEM  MODULES 

See  Air  Defense  System  Modules. 

TACTICAL  SCENARIO 

The  Air  Scenario  p3us  specification  of 
critical  assets  and  the  air  defense  con¬ 
figuration  (number,  type  and  location  of 
weapons  and  the  command  and  control  system) . 

TACTICAL  SCENARIO 
COMPONENT 


TASK  ELEMENTS 


As  element  of  a  Tactical  Scenario,  e.g., 
if  a  Tactical  Scenario  contains  several 
Q-73's,  each  one  is  a  Tactical  Scenario 
Component. 


Sue  Operator  Task. 


Individual  operator  actions  vhich,  vhen 
grouped  appropriately,  make  up  operator 
tasks.  Task  elements  are  usually  repre¬ 
sented  by  single  SAIKT  TASK  nodes  in  Air 
Defense  System  Modules. 


TASK  NODE 


A  modeling  symbol  used  in  the  SAIHT  simula¬ 
tion  language.  A  TASK  node  represents  an 
activity;  depending  upon  the  modeling  cir¬ 
cumstances,  a  TASK  node  may  represent  an 
individual  activity  such  as  a  Task  Element, 
or  it  may  represent  an  aggregated  activity 
such  as  an  entire  Operator  Task. 


TASK  SEQUENCING 
MODERATOR 
FUN  a  I  UN 


A  mathematical/logical  relationship  vhich 
selects  the  next  Operator  Task  vhich  an 
operator  vill  perform.  The  selection  is 
based  upon  operator  goal  seeking  character¬ 
istics. 


Additional  Terminology  and  Abbreviations 


Azimuth  Speed  Operator 
Battery  Control  Central 
Firing  Console  Operator 
Platoon  Command  Post 
Tactical  Control  Assistant 
Tactical  Control  Officer 


1. 


INTRODUCTION 


1- 0  PURPOSE 

This  document  is  a  user  manual  for  the  IHAWK  system  module. 

It  contains  details  of  the  implementation  of  the  MOPADS  model  of 
the  IHAKTC  system.  This  information  is  found  nowhere  else  in  the 
MOPADS  documentation. 

In  particular,  the  contents  of  the  operator  state  vectors, 
environmental  state  vectors,  and  task  data  are  given  in  this  report. 
Section  II  contains  a  brief  description  of  the  IHAWK  missile  system. 
Section  III  presents  the  contents  of  the  operator  state  vectors. 

The  environmental  state  vector  is  described  in  Section  IV.  The 
operator  tasks  and  task  sequencing  assumptions  are  given  in 
Section  V.  Finally,  Section  VI  describes  assumptions  used  in 
developing  the  module . 

2- 0  INTENDED  AUDIENCE 

MOPADS  users  and  MOPADS  modelers  should  read  this  report.  The 
language  and  level  of  detail  used  in  the  discussion  is  oriented  to 
the  MOPADS  user,  however.  Programming  and  implementation  details 
are  not  included  here.  That  information  is  discussed  in  detail  in 
MOPADS  volumes  four  and  five. 

3- 0  OTHER  READING 

The  reader  is  presumed  to  be  familiar  with  the  MOPADS  system. 
This  implies  that  he/she  should  have  read  the  final  report, 

Polito  &  Lauchery  (3983) ,  prior  to  reading  this  document.  In 
addition,  the  reader  should  be  familiar  with  the  main  MOPADS  user 
manual,  Polito  (19?3a).  More  technical  data  on  the  IHAWK  system 
module  is  found  in  Goodin  &  Walker  1983. 
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II.  SYSTEM  DESCRIPTION 


The  IHAWK  missile  battery  is  comprised  of  the  the  BCC,  IFF 
equipment,  several  radars  (IPAR,  IHIPIR.CWAR)  and  missiles  and 
leunchers.  The  primary  mission  of  the  IHAWK  missile  battery  is 
to  protect  vital  assets  such  as  airfields,  ammunition  supply 
centers,  etc.,  from  enemy  air  attacks.  The  IHAWK  has  the  ability 
to  detect,  identify,  track,  and  engage  aircraft  flying  at  various 
altitudes. 

The  various  radars  serve  different  operations  for  the  IHAWK. 

The  IPAR  is  used  to  detect  medium  to  high  altitude  aircraft.  The 
CWAR  is  used  to  detect  high-speed  low  flying  aircraft.  The  IHIPIR 
tracks  targets  that  are  being  engaged.  The  IHAWK  battery  has  two 
firing  sections  (A  and  3),  each  vith  its  own  set  of  three  launchers. 
Each  launcher  is  capable  of  holding  three  missiles  that  are  ready 
to  launch.  Additional  missiles  are  kept  on  pallets  near  the 
launchers  so  that  they  may  be  reloaded  once  they  have  expended  all 
of  their  "hot"  missiles.  The  launchers  are  capable  of  firing  one 
missile  at  a  time. 

The  BCC  is  responsible  for  control  of  the  IHAWK  missile 
battery's  firing  operations.  There  are  five  operators  manning  the 
BCC.  The  following  forms  describe  these  operators,  their  missions, 
and  their  duties. 

The  IHAWK  system  nodule  represents  the  operators  of  the  Improved 
Battery  Control  Central  (IBCC)  unit.  In  the  following  forms,  the 
MOPADS  operator  type  is  shown  in  the  column  labeled  OPERATOR  NUMBER, 
and  the  MOPADS  label  for  each  operator  is  shown  in  parentheses  in 
the  column  labeled  OPERATOR  TITLE. 
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III.  OPERATOR  nATA 


1-0  TACTICAL  CONTROL  OFFICER  (TCO) 

3-1.  Hus  an  Factors  Parameters. 

Table  III-l  shovs  the  default  valves  for  the  human 
factors  parameters  of  the  Tactical  Conrol  Officer  (TOO).  This 
data  is  part  of  the  operator  state  vector  for  the  TCO.  Discus¬ 
sions  of  these  variables  art  contained  in  Polito  &  Laughery 
(1983  ),  Laughery  0.9 83),  and  Polito  (1983b). 

TVs  last  elements  of  this  list,  X-SCHEEN- CENTER,  Y-SCPEEK- 
CENl’EP,  and  SCREEN-RANGE,  are  set  when  the  system  module  is 
copied  into  a  command  and  control  configuration. 
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Taole  III -3..  TCO  Human  Factors  Parameters. 


37.00000 

1.000000 

O.OOOOOOOE+OO 

O.OOOOOOOE+OO 

1.000000 

O.OOOOOOOE+OO 

100.0000 

8.000000 

16.00000 

O.OOOOOOOE+OO 

O.OOOOOOOE+OO 

57.00000 

O.OOOOOOOE+OO 

3.000000 

360.0000 

O.OOOOOOOE+OO 

O.OOOOOOOE+OO 

O.OOOOOOOE+OO 

1.000000 

O.OOOOOOOE+OO 

O.OOOOOOOE+OO 

1.000000 

40.00000 

O.OOOOOOOE+OO 

O.OOOOOOOE+OO 

1.000000 

1.000000 

8.000000 

1.000000 

6.000000 

1,000000 

2.000000 

1.000000 


CORE-TEMPERATURE 

CIO-VALUE 

TIME-ON-TASK 

DAYS-OF-DUTY 

SEARCH-DIMENSIONS 

NUMBER-FIRE-UNITS 

PERCENTAGE-RECOVERY 

PREVIOUS-WORK 

PREVIOUS-REST 

FLASH- INTENSITY 

TARGET-SPEED 

TARGET-TYPE 

TARGET-SIZE 

TARGET-COLOR 

SEARCH-AREA 

BINOCULAR-USAGE 

SLANT-RANGE-TO-TARGET 

TARGET-TRAJECTORY 

TARCET-BAKGRND-COMPLEXITY 

NUM-BACKGROUNB-CHARACTERS 

MESSAGE-BACKLOG 

SIGNALS-PER-MINUTE 

HOURS -UORKED-PER- WEEK 

DAYS-UITHOUT-SLEEP 

R A YS-DF- NIGHT- DUTY 

SIMULTANEOUS-TASKS 

CONTRAST-RATIO 

AVE-HOURS-SLEEP 

OBJECTIVE-FUNCTION 

GOALS-CONSIDERED 

TARGET-BRIGHTNESS 

NIGHTS 

SKY-GROUND-RATIO 
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Table  III-l  (continued) 


B 


O.OOOOOOOE+OO 

AIRCRAFT- ALTITUDE 

1 

4.000000 

METEOROLOGICAL-ROUGE 

1.000000 

THRESHOLD-CONTRAST 

0 . 6250000E-01 

TARGET-HEIGHT 

r* 

0.6250000E-01 

TARGET-WIDTH 

j u 

0.0000000E+00 

TARGET-DEPTH 

15 

O.OOOOOOOE+OO 

HORIZONTAL-RANGE 

1 .000000 

NUM-OF -RESOL UTION-ELEH 

1.000000 

NUM-DF-SUSPECT- AREAS 

O.OOOOOOOE+OO 

AIRCRAFT-SPEED 

i 

360.0000 

KIELD-OF-VIEU 

O.OOOOOOOE+OO 

OBSERVER -OFFSET 

O.OOOOOOCE+OO 

UNUSED 

C2 

5.000000 

DISPLAY-TARGET -LOCATION 

IS 

O.OOOOOOOE+OO 

TARGET-LOCATION 

•Si 

480.0000 

DISPLAY-RESOLUTION 

0.1000C00 

DISPLAY-BACK GROUND- HEIGHT 

0.1000000 

DISPLAY-BACKGRO'JND-UIDTH 

£9 

0.1000000 

DISPLAY- BACKGROUND- DEPTH 

1.330000 

DI3TANCE-T0-DI SPLAY 

1.000000 

DISPLAY-HEIGHT 

1.000000 

DISPLAY-UIDTH 

10.00000 

TARGET-NOISE-LEVEL 

**  * 

1.000000 

TARGET-DURATION 

Hi 

20.00000 

EXPERIENCE 

0.1000000 

SIGNAL-PROBABILITY 

1.000000 

REST-PERIODS 

O.OOOOOOOE+OO 

TASK-ERROR-FACTOR 

u 

O.OOOOOOOE+OO 

TASK-ELEMENT-ERROR-FACTOR 

O.OOOOOOOE+OO 

DAYS-SINCE- PRACTICE 

1.000000 

SENSE-OF- DIRECTI  ON 

t'A 

20.00000 

SKIN-TEMPERATURE 

M 

240.0000 

TIME- IN- TEMPERATURE 

20.00000 

PREVIOUS-SKIN-TEMPERATURE 

—  9999 .000 

X-3CREEN-CENTER 

-9999.000 

Y -SCREEN -CENTER 

ft 

-9999.000 

SCREE N-RANGE 

m 

1-2.  Goals ,  Goal  Priority  Functions,  and  Objective 
Parameters. 


There  are  eight  goals  defined  for  the  IHAWK  operators. 
Figure  III-l  explains  the  goals  and  the  goal  states.  Not  all  opera¬ 
tors  have  all  goals.  The  TCO  has  goals  1,  2,  3,  5>  6,  and  7.  The 
first  three  goals  involve  assessing  the  threat  priority  of  tracks 
according  to  the  criteria  specif ied  in  Table  III-l.  Goal  one  is 
effective  only  if  the  IHAWK  is  working  with  a  Battalion  AN/TSQ-73 
which  is  assigning  tracks  to  it. 


'i 


yj 


Each  track  is  evaluated  to  calculate  its  time  to  arrive  at 
the  IHAWK  and  at  the  protected 'Site.  The  minimum  of  these  two 

times  is  the  threat  for  the  track.  The  TCO  may  elect  to  attack  a  ki3 

track  other  than  the  one  assigned  by  the  Battalion  if  it  becomes  a 

high  enougn  threat.  j 
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Goal  five  represents  the  action  of  the  operators  to  respond  to 
ccsnmmi  cat  ions  frcm  other  members  of  -he  THAWX  battery  and  from 
Battalion.  The  MOPADS  software  uses  '’messages"  to  represent  these 
communications ,  and  each  message  has  at  associated  priority. 

The  IHAWK  will  not  attach  low  threat  targets  if  it  is  low  on 
missiles.  Goal  six  provides  this  disincentive  to  to  engage  vhen 
the  threat  is  not  high. 

Pop-up  targets  that  appear  as  high  threat  targets  on  CWAR  may 
he  engaged  before  being  identified.  Goal  seven  will  cause  the  TCO 
to  break  off  an  engagement  if  a  currently  engaged  target  is  detei 
mined  to  he  friendly. 

Goal  priority  functions  must  be  specified  for  the  goals  which 
specify  how  the  goal  priority  changes  with  differing  values  for 
the  goal  states.  As  discussed  in  Polito  t  Laughery  (1983b)  and 
Polito  (1983c),  this  3s  done  by  specifying  two  points  on  the  goal 
priority  function  above  and  below  the  range  of  satisfaction.  This 
data  for  the  TCO  is  shown  in  Figure  III-2. 

Table  II1-2  shows  how  this  data  appears  in  the  oner at or  state 
vector.  Each  goal  is  represented  by  15  values  the  first  of  which 
is  the  goal  number.  If  this  number  is  negative  (e.g.,  goal  four) 
then  the  operator  does  not  have  that  goal.  The  data  shown  in 
Figure  HI-2  is  given  in  the  elements  LITT1E-M,  BIG-M,  and  elements 
GOAL-STATE-LOW-1  through  PRIORITY -HIGH-2.  The  values  of  LITTLE-A, 
LITTLE-B,  BIG-A,  and  BIG-B  are  calculated.  See  Polito  (1903a)  for 
warnings  on  changing  these  numbers.  Infinity  is  represented  in  the 
operator  state  vector/  by  the  number  10i0. 

Objective  'unction  parameters  for  the  TCO  are  contained  in  his 
operator  state  vector.  Table  III-l.  The  objective  function  is 
specified  as"l".  which  means  that  the  TCO  selects  the  task  which 
offers  the  greatest  improvement  in  his  goal  state.  If  objective 
function  "2"  is  specified,  the  TCO  attempts  to  obtain  the  greatest 
goal  improvement  per  unit  time.  Finally ,  the  Tcjbj  considers  all  of  • 
his  goals  when  selecting  his  next  task  (i.e.,  GGIaLS-CCFSIDERED  is 
six) . 

1-3.  Display  Data. 

Table  III-3  is  the  display  data  for  the  TCO.  As  can  be 
seen  from  the  table,  only  three  elements  of  display  data  are  used 
by  the  current  model.  Screen  range  is  13  miles.  The  coordinates 
of  the  center  of  the  TCO’s  screen  are  not  specified  until  the  system 
module  is  copied  into  a  command  and  control  configuration.  At  that 
time,  the  user  may  specify  the  position  of  the  center  of  the  TCO's 
viewing  area.  If  the  user  fails  to  specify  this  data  (by  editing  the 
operator  state  vector),  then  MOPADS  will  set  it  equal  to  the  position 
of  the  IHAWK. 
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Table  III-2.  TCO  Goal  Priority  Function  pp.raapters . 


*V 


1.000000 
4 • 000000 
0 . 1000000E+11 
3. 099663 
1.1792-}? 
O.OOOOOOOE+OO 
O.OOOOOCOE+OO 
1.300000 
10.00000 

2.500000 
5.000000 

O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
2.000000 
■4 . 000000 
0.1000000E+11 
1.003522 
2.309685 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
1.300000 
10.00000 
2.000000 
5.000000 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOr +00 
O.OOOOOOOE+OO 
3.000000 
4.000000 
0.1 000000E+ 1 1 
0 . ttOl 1135 
2 . 489846 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
1.300000 

9.500000 
2.000000 

4.500000 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
-4.000000 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 

'  O.OOOOOOOE  +  OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 


GOAL 

LITTLE-H 

BIG-M 

LITTLE-A 

LITTLE-B 

BIG-A 

BIG-B 

G0AL-3T  ATE-LOU-1 

FRICRITY-LOU-1 

GOAL- ST  ATE-LOU-2 

F'RIQRITY-LOU-2 

GOAL-STATE-HIGH-1 

FRIORITY-HIGH-l 

GOAL-STATE-HIGH-2 

F'RIORITY-HIGH-2 

GOAL 

LITTLE-H 

BIG-H 

LITTLE-A 

LITTLE-B 

BIG-A 

BIG-B 

GOAL -ST  ATE -LOU- 1 
PRIORITY -LOU-1 
GOAL-STATE -LOU-2 
FRI0RITY-L0U-2 
GOAL-STATE-HIGH-1 
F'RIORIT  Y-HIGH-1 
GOAL-STATE-HIGH-2 
F'RIORIT  Y-HIGH-2 
GOAL 

LITTLE-M 

BIG-H 

LITTLE-A 

little-b 

tlG- A 
BIG-B 

GOAL-STATE-LOU-1 

PRIDRITY-LOU-l 

G0AL-STATE-L0U-2 

PRIORITY -LOU- 2 

GOAL-STATE-HIGH-1 

PRIORITY-HIGH-1 

GOAL -ST ATE-HIGH- 2 

PRIORITY-HIGH-2 

GOAL 

LITTLE-M 

BIG-M 

LITTLE-A 

LITTLE-B 

BIG-A 

BIG-B 

SOAL-STATE-LOU-1 
PRIORITY -LOU-1 
GOAL-ST ATE-LOU-2 
PRIORITY -LOU-2 
GOAL-STATE-HIGH-! 
PRIORITY-HIGH-1 
GOAL-STATE-HIGH-2 
F'RIORITY-HIGH-2 
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Table  III-2  (continued) 


5.000000 

GOAL 

O.OOOOOOOE+OO 

LITTLE-M 

O.AOOOOOOE+OO 

BIG-H 

1.000000 

LITTLE-A 

1 .000000 

LITTLE-B 

1.000000 

B1G-A 

1.000000 

BIG-B 

-1.000000 

GO AL- 3 TATE -LOU- 1  • 

1.000000 

PRIOR ITY-LOU-1 

-2.CCCC00 

GOAL-STATE -LOU-2 

2.000000 

FR1QRITY-LDW-2 

1. cococo 

G0AL-3T  ATE -HIGH- 1 

1.000000 

f RIORITY-HIGH-1 

2 • 00C  000 

GOAL-STATE -HIGH-2 

2.000000 

pRIORITY-HIGH-2 

6.000000 

GOAL 

3.000000 

LITTLE-M 

0. 1000000E+ 1 1 

IIG-M 

5.000000 

little-a 

O.OOOOOOOE+OO 

LITTLE-B 

O.OOOOOOOE+OO 

B I G- A 

O.OOOOOOOE+OO 

BIG-B 

2.500000 

GOAL- ST  ATE-LDU-1 

5.000000 

PRIORITY-LOU-1 

O.OOOOOOOE+OO 

GOAL- STATE -LOU- 2 

5.000000 

FRI0RITY-L0U-2 

O.OOOOOOOE+OO 

GOAL -ST  ATE-HIGH-1 

O.OOOOOOOE+OO 

FRIORITY-HIGH-1 

O.OOOOOOOE+OO 

GOAL-STATE-HIGH-2 

O.OOOOOOOE+OO 

F  RIQRITY-HIGH-2 

7.000000 

GOAL 

— 0. 1000000E+11 

LITTLE-M 

O.OOOOOOOE+OO 

BIG-M 

O.OOOOOOOE+OO 

LITTLE-A 

O.OOOCOOOE+OO 

LITTLE-B 

9 • SOOOOO 

BIG-A 

0. 1464670E-01 

BIG-B 

O.OOOOOOOE+OO 

GOAL-STATE-LOU-1 

O.OOOOOOOE+OO 

F'RIORITY-LOU-1 

O.OOOOOOOE+OO 

GOAL -ST AT E-LOU-2 

O.OOOOOOOE+OO 

F R I ORIT Y-LOU-2 

1.000000 

G0AL-3TATE-HIGH-1 

9 . 800000 

FRIORITY-KIGH-1 

2.000000 

GOAL-STATE-HIGH-2 

9.900000 

FRIORITY-HIGH-2 

Table  III-3.  TCO  Display  Data. 

O.OOOOOOOE+OO 

UNUSED 

O.OOOOOOOE+OO 

UNUSED 

O.OOOOOOOE+OO 

UNUSED 

O.OOOOOOOE+OO 

UNUSED 

O.OOOOOOOE+OO 

UNUSED 

O.OOOOOOOE+OO 

UNUSED 

43.00000 

SCREEN-RANGE 

-9999.000 

SCREEN-X 

-9999.000 

SCREEN-Y 

O.OOOOOOOE+OO 

UNUSED 

B-24 


£-0  TACTICAL  C0KTB0L  ASSIST AUT  (TCA) 
2-1.  Human  Factors  Parameters. 


Table  III-U  contains  the  human  factors  parameters  for  the 
Tactical  Control  Assistant  (TCA).  The  comments  in  Section  1-1  apply 
equally  to  the  data  for  the  TCA. 

2-2.  Goals.  Goal  Priority  Functions,  and  Objective  Parameters. 


The  TCA  has  goals  four  and  five  from  Figure  III-l.  Goal 
four  causes  the  TCO  to  identify  unknown  tracks,  and  goal  five  causes 

Table  III-U.  TCA  Human  Factors  Parameters. 


37.00000 
1.000000 
0 • OOGOOGOE+OO 
O.OOOOOOOE+OO 
1.000000 
O.OOOOOOOE+OO 
100.0000 
8.000000 
1 A . 00000 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
57.00000 
O.OOOOOOOE+OO 
3.000000 
360.0000 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
1.000000 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
1.000000 
40.00000 
O.OOOOOOOEJ  00 
O.OOOOOOOE+OO 
1.000000 
1.000000 
8.000000 
1.000000 
2.000000 
1.000000 
2.000000 
1.000000 
O.OOOOOOOE+OO 
4.000000 
1 .000000 
•0, 6250000E-01 
0 . 6250000E-01 
0. OOOOOOOt+OO 
O.OOOOOOOE+OO 
1.000000 
1  .000000 
O.OOOOOOOE+OO 
360.0000 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 


CORE- TEMPERATURE 

CIO-VALUS 

TIHE-GN-7  ASK 

DAYS-CF-DUTY 

SEARCH- D1 HEMS 10 NS 

NUMBER-FIRE-UNITS 

PERCENTAGE-RECOVERY 

PREVIOUS-UORK 

PREVIOUS-REST 

FLASK-INTENSITY 

TARGET— SPEED 

TARGET-TYPE 

TARGET-SIZE 

TARGET-COLOR 

SEARCH-AREA 

BINOCULAR-USAGE 

SLAHT-RANGE-TO-TARGET 

TARGET-TRAJECTORY 

TARGET-BAKGRND-COHPLEXITY 

NUM-BACKGF.'DUND-CHARACTERS 

MESSAGE-BACKLOG 

SIGNALS-PER-MINUTE 

HOURS-UORKED-PER-UEEK 

DAYS-UITHOUT-SLEEP 

DAY3-QF-NIGHT--DUTY 

SIMULTANEOUS-TASKS 

CONTRAST-RATIO 

AVE- HOUR 3- SLEEP 

OBJECTIVE-FUNCTION 

GOALS-CONSIDERED 

TARGET-BRIGHTNESS 

NIGHTS 

SKY-GROUND-RATIO 

AIRCRAFT-ALTITUDE 

METEOROLOGICAL-RANGE 

THRESHOLD-CONTRAST 

TARGET-HEIGHT 

TARGET-WIDTH 

TARGET-DEPTH 

HORIZONTAL-RANGE 

NUM-OF- RESOLUTION- EL EM 

NUM-OF- SUSPECT- ARE AS 

AIRCRAFT-SPEED 

FI  ELD- OF- VIEW 

OBSERVER-OFFSET 

UNUSED 
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Table  III-l*  (continued) 


5.000000 

DISPLAY-TARGET-LOCATION 

O.OOOOOOOE+OO 

TARGET-LOCATION 

430.0000 

DISPLAY-RESOLUTION 

0.1000000 

DI  SPLAY- BACKGROUND-HEIGHT 

0.1000000 

Dl SPL AY-BACKGROUND-UI DTH 

0.1000000 

DISPLAY-BACKGROUKD-DEPTH 

1.330000 

BI ST ANCE-TO-DI SPLAY 

1.000000 

DISPLAY-HEIGHT 

1.000000 

DISPLAY-WIDTH 

10.00000 

TARGET-NOISE-LEVEL 

1 .000000 

TARGET-DURATION 

20.00000 

EXPERIENCE 

0.1000000 

signal-probability 

1.000000 

REST-PERIODS 

O.OOOOOOOE+OO 

TASK-ERROR-FACTOR 

O.OOOOOOOE+OO 

TASK- ELEMENT- ERROR-FACTOR 

O.OOOOOOOE+OO 

DAYS-SINCE-PRACTICE 

1.000000 

SENSE-OF-DIRECTION 

20.00000 

SKIN-TEMPERATURE 

240.0000 

TIME-IN-TEMPERATURE 

20.00000 

PREVIOUS-SKIN-TEMPERATURE 

-9999.000 

X-SCREEN-CENTER 

-9999.000 

Y-SCREEN-CENTER 

-9999.000 

SCREEN-RANGE 

hln  to  attend  to  comuni  cations  iron  the  TCO  and  the  Azinuth-Speed 
Operator  (ASO).  The  goal  priority  data  for  the  TCA  is  shown  in 
Figure  III-3.  Table  III-5  shows  how  the  data  appears  in  the  opera¬ 
tor  state  vector. 

The  TCA  has  objective  function  one  as  does  the  TCO,  and  he 
considers  both  goals  in  task  sequencing. 

2-3.  Display  Data. 

The  TCA  has  the  sane  display  data  as  does  the  TCO.  See 
Table  III-3. 


UPEKATUR  COAL  SPECIFICATION 


Table  III-5*  TCA  Goal  Priority  Function  Parameters. 


4.000000 
-0. 1000000E+11 
■O.OOOOOOOE+OO 
v.OOOOGOGE+OO 
O.OOOOOOOE+OO 
2.000000 
0.5693234 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
1.000000 
2.000000 
5.000000 
5.000000 
5.000000 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
1.000000 
1.000000 
1.000000 
1.000000 
-1.000000 
1.000000 
-2.000000 
2.000000 
1.000000 
1.000000 
2.000000 
2.000000 


GOAL 

LITTLE-H 

BIG-H 

LITTLE-A 

LITTLE-B 

BIG-A 

EIG-B 

GOAL-STATE-LOW-1 

FRIORITY-LOU-1 

30AL-STA7E-L0U-2 

FRI0RITY-L0U-2 

GOAL-STATE-HIGH-1 

FRIORITY-HIGH-1 

GOAL-STATE-HIGH-2 

FRIORITY-HIGH-2 

GOAL 

LITTLE-H 

BIG-tt 

LITTLE-A 

LITTLE-B 

BIG-A 

BIG-B  • 

G0AL-3TATE-L0U-1 

FRIORITY-LOU-l 

G0AL-STATE-L0U-2 

PRIORITY-LOW-2 

GOAL- 3 1 ATE-HIGH-1 

FRIORITY-HIGH-1 

uOAL-STATE-HIGH-2 

FRIORITY-HIGH-2 


3-0  AZIMUTH-SPEED  OPERATOR  (ASO) 

3-1.  Hunan  Factors  Parameters. 

Table  III-6  contains  the  human  factors  parameters  for  the 
Azimuth  Speed  Operator  (ASO).  The  comments  in  Section  1-1  apply 
equally  to  the  datai:  for  the  ASO. 


3-2.  Goals,  Goal  Priority  Functions,  and  Objective  Parameters. 

l! 

The  ASO  hjaa  goals  five  (receive  messages)  and  eight  from 
Figure  III-l.  Goal  eight  causes  the  ASO  to  pass  lov  altitude  targets 
to  the  TOO  and  TCA  to  be  identified  and  engaged.  The  goal  priority 
function  daza  for  the  ASl  is  shvon  in  Figure  III-E  and  Table  III-7. 
The  ASO  uses  objective  function  one  and  considers  both  goals  in  task 
sequencing. 
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Table  III-6.  ASC  Human  Factors  Parameters. 


37.00000 
1.000000 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
1.000000 
O.OOOOOOOE+OO 
100.0000 
8.000000 
16. 00000 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
57.00000 
O.OCjOOOOE+OO 
3.000000 
360.0000 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
1.000000 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
1.000000 
40.00000 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
1.000000 
1.000000 
3.000000 
1.000000 
2.000000 
1.000000 
2.000000 
1.000000 
O.OOOOOOOE+OO 
4.000000 
1.000000 
0.2OeOOOOE-01 
0 . 2080000E-0 1 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
1.000000 
1.000000 
O.OOOOOOOE+OO 
360.0000 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
5.000000 
O.OOOOOOOE+OO 
240.0000 
0.1000000 
0.1000000 
0.1000000 
1.330000 
1.000000 
1.000000 
10.00000 
1.000000 
20.00000 
0,1000000 
1.000000 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 


CORE-TEMPERATURE 

C I O-VALUE 

TIME-QN-T*5K 

I'AYS-OF-DUTY 

SEARCH-DIMENSIONS 

NUMBER-Fi RE-UN ITS 

PERCENTAGE-RECOVERY 

PREVIOUS-UORK 

PREVIOUS-REST 

FLASH-INTENSITY 

TARGET-SPEED 

TARGET-TYPE 

TARGET-SIZE 

TARGET-COLOR 

SEARCH-AREA 

BINOCULAR-USAGE 

SLANT-RANGE-T O-TARGET 

TARGET-TRAJECTORY 

TARGET-BAKGRND-COMPLEXITY 

HUM-BACKGROUND- CHARACTERS 

MESSAGE-BACKLOG 

SIGNALS-PER-MIHUiE 

HOURS-UORKED-PER-WEEK 

DAYS-UITHOUT-SLEEP 

BAYS- OF -NIGHT-DUTY 

SIMULTANEOUS-TASKS 

CONTRAST-RATIO 

AVE-HDURS- SLEEP 

OBJECTIVE-FUNCTION 

GOALS-CDNSIDERED 

TARGET-BRIGHTNESS 

NIGHTS 

SKY-GROUND-RATIO 

AIRCRAFT-ALTITUDE 

METEOROLOGICAL-RANGE 

THRESHOLD-CONTRAST 

TARGET-HEIGHT 

TARGET-WIDTH 

TARGET-DEPTH 

HORIZONTAL-RANGE 

NUM-OF-RESOLUTION-ELEM 

NUM- OF- SUSPECT -ARE AS 

AIRCRAFT-SPEED 

FIELD -OF- VIEW 

OBSERVER-OFFSET 

UNUSED 

DISPLAY-TARGET-LOCATION 

TARGET-LOCATION 

DISPLAY-RESOLUTION 

PISPLAY-BACKGROUND-HEIOHT 

DISPLAY-BACKGROUND-UIDTH 

DISPLAY-BACKGROUND-DEPTH 

DISTANCE- TO- DISPLAY 

DISPLAY-HEIGHT 

DISPLAY-UIDTH 

TARGET-NDI SE-LEVEL 

TARGET-DURATION 

EXPERIENCE 

SIGNAL-PROBABILITY 

REST-PERIODS 

TASK-ERROR-FACTOR 

TASK-ELEHENT-ERROR-FACTOR 

DAYS-SINCE-PRACTICE 
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Table  III-6  (continued) 


1.000000 

20.00000 

240.0000 

20.00000 

-9999.000 

-9999.000 

-9999.000 

SENSE- OF -DIRECTI  OH 
3KIN-TEHPERATURE 

TIME-IN- TEMPERATURE 

P  F:EV  I OUS-SK  IN- TEMPERATURE 

X-SCREEN-CENTER 

Y-SCREEN-CENTER 

SCREEf-.-RANGE 

Table  III-7*  ASO  Goal  Priority 

Function  Parameters. 

5.000000 

GOAL 

O.OOOOOOOE+OO 

LITTLE-M 

O.OOOOOOOE+OO 

EIG-li 

1.000000 

LITTLE-A 

1.000000 

LITTLE-P 

1.000000 

PIG-A 

1.000000 

BIG-B 

-1.000000 

G0AL-3TATE-L0U-1 

1.000000 

PRIORITY-LOW- 1 

-2.000000 

GOAL -ST ATE -LOU-2 

2.000000 

PRIORITY-LOW- 2 

1.000000 

GOAL-STATE-HIGH-1 

1.000000 

FRIORITY-HIGH-l 

2.000000 

G0AL-3T AT E-HIGH-2 

2.000000 

PRIORITY-HIGH-2 

B. 000000 

GOAL 

-0. 1000000E+11 

LITTLE-M 

O.OOOOOOOE+OO 

BIG-M 

O.OOOOOOOE+OO 

LITTLE-A 

O.OOOOOOOE+OO 

LITTLE-B 

2.000000 

BIG-A 

0.3219281 

BIG-B 

O.OOOOOOOE+OO 

GOAL-STATE-LOU-1 

O.OOOOOOOE+OO 

PRIORITY- LOU-1 

O.OOOOOOOE+OO 

GOAL-ST AT E-LOU-2 

O.OOOOOOOE+OO 

F'RIORITY-LOW-2 

1.000000 

G0AL-5TATE-HIGH-1 

2.000000 

PRIORITY-HIGH-1 

2.000000 

GOAL-STATE -HIGH-2 

2.500000 

PRIORITY-HIGH-2 

3-3.  Display  Data 


E 

J 


The  ASO  has  the  sane  display  data  as  does  the  TCO.  See 
Table  III-3- 

li-0  FIRING  CONSOLE  OPERATOR  (FCO) 
k-i.  Hunan  Factors  Parameters. 


Table  III-8  contains  the  human  factors  parameters  for 
both  of  the  Firing  Console  Operator  (FCO).  Each  FCO  has  his/her  own 
operator  -ate  vector,  but,  in  the  default  case,  they  are  identical. 
The  conments  in  Section  1-1  apply  equally  to  the  data  for  the  FCO. 

1—2 .  Goals,  Goal  Priority  r unctions  .  and  Ob.1  active  Parameters. 


The  FCO's  have  only  goal  five  from  Figure  III-l.  The 
FCO's  respond  to  communications  from  the  TCO.  The  goal  priority 
function  data  is  shown  in  Table  III-9  and  Figure  IIx-5.  The  FCO's 
also  use  objective  function  one,  and  they  consider  their  one  goal 
in  task  sequencing. 


Table  III-8.  FCO  Human  Factors  Parameters. 


37.00000 
1.000000 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
1.000000 
O.OOOOOOOE+OO 
100.0000 
B. 000000 
16.00000 
O.OOOCOOGE+OO 
0.0000C00E+00 
57.00000 
O.OOOOOOOE+OC 
3.000000 
360.0000 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
1.000000 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
1.000000 
40.00000 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
1.000000 
1.000000 
8.000000 
1.000000 
1.000000 


CORE- TEMPERATURE 

Cl 0-VALUE 

TIME-ON-TASK 

BAYS-OF-DUTY 

SEARCH-DIMENSIONS 

NUMBER -FIRE-UNITS 

PERCENT AGE-RECOVERY 

PREVIOUS-WORK 

PREVIOUS-REST 

FLASH-INTENSITY 

TARGET-SPEED 

TARGET-TYPE 

TARGET-SIZE 

TARGET-COLOR 

SEARCH-AREA 

BINOCULAR-USAGE 

SLANT-RANGE-T 0-TARGET 

T  hRCET-TRAJECTOR,v 

T  ARGET- DAK  GRNIi -COMPLEXITY 

NUM-D  A CKGRO UN D- CHARACTERS 

MESSAGE-BACKLOG 

SIGNALS-PL'R-MINUTE 

HOURS-WORKED-FER-WEEK 

DAYS- WITHOUT- SLEEP 

DAYS-O17- NIGHT- DUTY 

SIMUL . eNEOUS-TASKS 

CONTRAST-RATIO 

AVE-HOURS-SLEEP 

OBJECTIVE-FUNCTION 

G0ALS-C0N3IDERED 
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Table  III-8  (continued) 


1.000000 
2. 000000 
1.000000 
O.OOOOOOOE+OO 
4.000000 
1.000000 
0.6250000E-01 
0.6230000E-01 
0.0000000E+00 
O.OOOOOOOE+OO 
1.000000 
1.000000 
O.OOOOOOOE+OO 
360.0000 
O.OOOOCOOE+OC 
O.OOOOOOOE+OO 
5.000000 
O.OOOOOOOE+OO 
480.0000 
0.1000000 
0.1000000 
0.1000000 
1.330000  * 
1.000000 
1.000000 
10.00000 
1.000000 
20.00000 
0.1000000 
1.000000 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
1.000000 
20.00000 
240.0000 
20.00000 
“9999 . 000 
-9999,000 
-2999.000 


TARGET-BRIGHTNESS 

NIGHTS 

SKY-GROUNIt-RATIO 

AIRCRAFT -ALT I TUBE 

METEOROLOGICAL-RANGE 

THRESHOLD- CONTRAST 

TARGET-HEIGHT 

TARGET-WIDTH 

TARGET-DEPTH 

HORIZONTAL-RANGE 

NUM-OF-RESOLUTION-ELEM 

NUH-0F-5USPECT-AREA3 

AIRCRAFT-SPEED 

FIELD-OF-VIEU 

OBSERVER-OFFSET 

UNUSED 

DISPLAY-TARGET-LOCATION 

TARGET-LOCATION 

DISPLAY-RESOLUTION 

DISPLAY-BACKGROUND-HEIGHT 

DISPLAY-&ACKGROUND-UIHTH 

D I SPLAY -BACKGROUND- DEPTH 

BIST  ANCEfTO-DI SPLAY 

DISPLAY-HEIGHT 

DISPLAY-WIDTH 

TARGET-NOISE-LEVEL 

TARGET-DURATION 

EXPERIENCE 

SIGNAL-PROBABILITY 

REST-PERIODS 

TASK-ERROR-FACTOR 

TASK-ELEMENT-ERROR-FACTOR 

DAY3-SINCE-PRACTICE 

SENSE-OF-DIRECTION 

SKIN-TEMPERATURE 

TIME-IN-TEMPERATURE 

PREVIOUS-SKIN-TEMPERATURE 

X-SCREEN-CENTER 

Y-SCREEN-CENTER 

SCREEN-RANGE 


Table  111-9 


L- 

See  Table  I 


FCO  Goal  Priority  Pucctica  Parameters. 


0 

0 


5. 000000 
• OOOOOOOE+OO 
• OOOOOOOE+OO 
1.000000 
1 .000000 
1.000000 
1 .000000 
1.000000 


1.000000 

-2.000000 

2.000000 

1.000000 

1.000000 

2.000000 

2.000000 


GOAL 

LITTLE-M 

BIP-M 


LITTLE-A 
LITTLE-B 
BIG- A 
BIG-* 

GOAL-STATE-LOU-1 

FRI0RITY-L0U-1 

GOAL-STATE-LOU-2 

FRIORITY-LQU-2 

GOAL-STATE-HIGH-1 

rF-IORITY-HlGH-l 

GOAL-STATE-HISH-2 

PRIORITY-HIGH- 2 


3-  Pisrlay  Oat a. 

The  FCO  has  the  same  display  data  as  does  the  TCO. 
1-3. 
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IV.  ENVIRONMENTAL  DATA 


Table  17-1  contains  the  HAWK  environmental  state  vector. 

The  various  parameters  in  this  vector  are  explained  in  Polito 
(1983a).  The  user  should  note  that  the  default  sampling  option  is 
three  ( deterministic ,  moderated) ,  and  that  each  fire  section  has 
nine  hot  and  nine  cold  missiles. 


Table  IV-1.  User  Statistics  for  the  IHAWK. 


O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
0.0000000E+00 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
9.000000 
9.000000 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOCOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
O.OOOOOOOE+OO 
3.000000 
22.00000 
So. 00000 
6.000000 
45.00000 
50.00000 
5.000000 
O.OOOOOOOE+OO 
10.00000 
O.OOOOOOOE+OO 


SYSTEM-MODE 

OPERATOR-MODE 

UNUSED 

METHOD-OF-CONTROL 
liEAPONS-CONTOL- STATUS 
UNUSED 

INITIAL-AMMUNITION-HOT 

INITIAL-AMMUHIT ION-COLD 

UNUSED 

UNUSED 

UNUSED 

UNUSED 

UNUSED 

UNUSED 

UNUSED 

UNUSED 

UNU5ED 

X-P03ITI0N 

Y-POSITIQN 

Z-POSITION 

SAMPLING-OPTION 

DRY-BULB-TEMPERATURE 

F.ELAT1UE-HUMIDITY 

AIR- MOVEMENT-RATE 

NOISE-LEVEL 

WORKING-AREA- ILLUMINATION 

NUMBER-ON-DUTY 

VIBRATION 

AMB I ENT-VAPOP -PRESSURE 
NOISE-PREDICTABILITY 


V,  OPERATOR  TASKS 


V  i-; 


<■.  V, 
a*  '  - 


A*,  ,  . 

%* 
v 
\ 

V 


THAWK  operator  tasks  are  given  below.  Each  task  is  numbered 
and  has  a  title.  A  brief  description  of  each  task  is  given  here 
and  the  operator  that  performs  the  task  is  identified.  Complete 
descriptions  and  MSAXHT  models  of  the  tasks  are  contained  in 
Goodin  &  Walker  1983. 


Task 

Number 


Title  or  Description 


Operator 


1  ASO  Standby  Wait  For  Action  -  ASO 
monitors  CWAR  radar  video  for  new 
targets. 

2  Detect  Target  on  CWTDC  -  ASO  observes 
target  video  on  CRT  and  hears  target 
doppler  in  headset. 

3  Establish  Target  Priority  -  ASO  ranks 
the  priority  of  the  current  target 
verses  outstanding  alerts  and  other 
target  video. 

U  Preempt  Lower  Priority  Alert  -  ASO 

asks  permission  from  TCO  to  cancel 
the  current  TCC  alert  because  he  has 
a  higher  threat  target. 

5  TCC  Alert  -  ASO  alerts  TCA  of  the  highest  ASO 

threat  CWAR  target  that  has  not  been 
previously  alerted. 

6  Mark  Target  As  Accepted  by  TCC  -  After  the  ASO 

ASO  alerts  TCA  in  Task  5  and  the  TCA 

accepts  the  target  the  ASO  will  mark  the 
target  on  the  CRT  as  accepted. 

T  FCO,  Standby  Wait  For  Action  -  FCO  monitors  FCO 

CRT  and  control  panel  and  awaits  assign¬ 
ment  or  engage  commands  from  the  TCO. 

8  Track  Target  -  FCO  follows  the  action  of  the  FCO 

ADP  as  it  tracks  the  target  and  attempts  to 
acquire  a  IHIPIR  lock. 


ASO 


ASO 


ASO 


ASO 
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Tack 

Number 

9 

10 

11 

t- 

12 

13  • 

lk 

15 

16 

17 

18 


Title  or  Description 


Operator 


Obtain  Lock  On  Target  Manually  -  FCO 
performs  the  actions  required  to 
acquire  an  IHIPIR  lock  manually. 

(BOTE:  This  task  is  performed  for 
targets  that  are  assigned  by  the  Qf73, 
or  are  out-of-sector,  or  *re  CWAR 
only  targets.) 


FCO 


L 
E 


Put  Fire  Section  Out-of-Action  -  All 

hot  missiles  have  been  expended  so 

FCO  places  the  fire  section  out-of-action. 


FCO 


Estimate  Raid  Size  -  The  FCO  monitors 


FCO 


doppl) 


(one 


er  and  video  returns  and  makes  an 


estimate  as  to  the  size  of  the  raid 


jfev,  or  many). 


Select  Launcher  -  The  FCO  manually  selects  FCO 
a  launcher  to  fire  the  next  missile 
(A,  B,  or  C). 


a 


Fire  Missiles  -  The  FCO  fires  the  number 
of  missiles  indicated  by  the  TCO's  fire 
command. 


FCO 


§ 


Evaluate  Target  Intercept  -  The  FCO  moni-  FCO 
tors  doppler  and  video  returns  and  deter¬ 
mines  the  outcome  of  the  engagement. 

0 

Put  Fire  Section  Back  'in  Action  -  FCO  FCO 

returns  the  fire  section  to  active  after 
missile  reloading. 

Process  Change  Targets  Command  -  FCO  FCC 

breaks  the  IHIPIR  lock  on  the  target 
according  to  orders  from  the  TCO. 

TCA  Monitor  CRT,  Controls,  Indicators  -  TCA 

The  TCA  monitors  the  TCC  screen  and  IFF 
returns  awaiting  target  classification 
(friend,  foe,  neutral)  or  a  new  CWAR 
target  from  the  ASO. 

Accept  CWTDC  Target  From  ASO  -  The  TCA  TCA 

accepts  control  of  a  high  threat  target 
picked  up  by  the  ASO  on  the  CWTDC.! 


•4 


ft 


V* 


'V 

y 


& 


B-40 


Task 

Humber 

19 

20 

21 

22 

23 

2U 

25 

26 

27 

28 


* 


Title  or  Description  Operator 


IFF  Challenge  -  The  TCA  monitors  IFF  TCA 

returns  and  determines  the  IHAWK 
batteries  identification  of  the 
target . 

Mark  on  Reflection  Plotter  -  The  TCA  TCA 

indicates  the  battery's  identification 
of  the  target  on  the  reflection  plotter. 

TCO  Monitor  CRT,  Controls,  Indicators  -  TCO 
The  TCO  monitors  his  CRT  to  locate  new 
high  threat  targets.  The  TCO  also  moni¬ 
tors  communication  with  the  Q-73  and 
other  operators  in  the  BCC. 

Detect  and  Assign  IPAR  Target  -  TCO  will  TCO 
assign  an  in-sector  IPAR  target  to  a  fire 
section. 

Manually  Assign  Targets  -  TCO  performs  a  TCO 
manual  assignment  of  a  track  to  a  fire 
section.  (NOTE:  This  is  used  to  assign 
Q-73,  out-of-sector,  and  CWAR-only  targets 
to  a  fire  section.) 

IHIPIR  Tracking  -  TCO  learns  information  TCO 
concerning  raid  size  and  fire  section 
readiness  and  determines  which  fire 
command  to  issue. 

Send  Cannot  Comply  to  Q-73  -  TCO  has  TCO 

determined  that  IHAWK  cannot  act  on 
target  as  instructed  by  the  Q-73. 

Higher  Priority  Target  To  Be  Assigned  -  TCO 

The  TCO  has  located  a  target  with  a 
higher  threat  than  a  currently  assigned 
target. 

Process  A  Hostile  (Give  Fire  Command)  -  TCO 

The  TCO  orders  the  FCO  to  fire  missiles 
at  a  target. 

Assigned  Target  Determined  Friendly  -  The  TCO 
TCO  orders  the  FCO  to  break  lock  on  the 
currently  engaged  target  because  it  has 
been  identified  as  friendly. 
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Task 

Humber 


Title  or  Description 


Operator 


29  Process  A  Friend  -  The  TCQ  sends  infor-  TCO 

nation  along  the  ATDL  specifying  a 

target  to  be  a  positively  identified 
"true"  friend. 

30  Evaluate  Whether  More  Missiles  Are  To  Be  TCO 

Fired  -  The  TCO  determines  vh ether  or  not 

to  continue  an  unsuccessful  engagement. 

31  Give  ASO  Permission  To  Cancel  Alert  -  TCO  TCO 

allows  the  ASO  to  cancel  the  current  TCC 

alert  so  a  higher  threat  target  may  be 
alerted. 

32  Receive  Message  -  Task  to  allow  TCO  to  TCO 

receive  messages  from  the  Q-73  and  the 

other  IHAWX  operators. 

35  Process  "HOLD  FIRE"  command  -  TCO  per-  TCO 

forms  necessary  actions  so  IHAWK  will 
comnly  to  the  HOLD  FIRE  command  issued 
by  the  Q-73. 

37  Process  "CEASE  ENGAGED"  Command  -  TCO  per-  TCO 

forms  necessary  actions  so  IHAWK  will 
comply  to  the  CEASE  ENGAGED  command 
issued  by  the  Q-73. 

Uo  Task  Sequencing  ALL 
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VI.  OTHER  FEATURES 


1- 0  MISSILE  FLIGHT 

Missile  flight  times  are  calculated  using  the  distance  between 
the  IHAWK  and  the  aircraft  at  time  of  launch.  A  constant  missile 
speed  of  approximately  2000  miles  per  hour.  Missile  flight  time  is 
calculated  in  SUBROUTINE  FLTY  (Goodin  &  Polito  1983).  More  complex 
flight  time  considerations  can  be  obtained  by  re-writing  this 
program. 

FUNCTION  KILLTW  (Goodin  &  Walker  1933)  determines  whether  or 
not  a  missile  destroys  its  target.  The  current  implementation 
assumes  that  missiles  are  always  effective.  This  can  be  changed 
by  re-writing  KILLTW. 

2- 0  RADAR  LOCK 

Whether  the  IHIPIR  obtains  a  lock  on  a  particular  track  i3 
determined  by  FUNCTION  IDLCKW  (Goodin  &  Walker  1983).  Currently 
it  is  assumed  that  radar  lock  is  always  obtained,  but  this  can  be 
changed  by  re-writing  IDLCKW. 

3- 0  ESTIMATION  OF  RAID  SIZE 

FUNCTION  IRDSZW  (Goodin  &  Walker  1983)  determines  the  FCO's 
perception  of  the  track  multiplicity.  Currently,  it  is  assumed 
that  the  FC0  is  100/E  accurate.  This  can  be  changed  by  re- writing 
IRDSZW. 

U-0  IFF 

FUNCTION  IFFNW  (Goodin  &  Walker  1983)  determines  the  accuracy 
of  an  IFF  challenge.  Currently,  it  is  assumed  that  IFF  is  ICO* 
accurate.  This  can  be  changed  by  re-vriting  IFFNW. 

5-0  TARGET  SELECTION 

The  TC0  uses  the  following  procedure  in  selecting  targets. 
First  there  must  be  three  hot  missiles  available  and  one  fire 
section  ready. 


Most  Threatening  Track  Is: 


Greater  than  2  minutes  avay 
(approx.  30  Km) 


Between  1.3  and  2.0  min. 
away  (approx.  20-30  Km). 


Less  than  1.3  min.  away 
(approx.  20  Km) 


Then 


Select  assigned  Track  from 

Battalion  if  one  exists. 

Otherwise,  do  not  engage. 

a)  If  the  track  is  CWAR,  select 
it  over  a  track  assigned  by 
Battalion. 

b)  If  the  track  is  IPAB  only, 
select  the  track  assigned  by 
Battalion  if  one  exists. 
Otherwise,  engage  the  track. 

Eigage  it  instead  of  a  track 

assigned  by  Battalion. 


§ 

B 


S 


B 

sA 


f: 

WU 

y 

ft 
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VII.  STATISTICS 


Figure  VII-1  shows  the  statistics  maintained  by  the  IHAWK 
system  module.  These  statistics  are  in  addition  to  the  task 
fraction  statistics  collected  by  MOPADS  for  all  system  modules. 
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MOPADS  Terminology 


AIR  DEFENSE  SYSTEM 

A  component  of  Air  Defence  which  includes 
equipment  and  operators  and  for  which 
technical  and  tactical,  training  arerequired. 
Examples  are  IKAWK  and  the  AN/TSQ-73. 

AIR  DEFENSE  SYSTEM 
MODULE  (ADSM) 

Models  of  operator  actions  and  equipment 
characteristics  for  Air  Defense  Systems  in 
the  MOPADS  software.  These  models  are  pre¬ 
pared  with  the  SAINT  simulation  language. 

Air  Defense  System  Modules  include  the 

SAINT  model  and  all  data  needed  to  com¬ 
pletely  define  task  element  times,  task 
sequencing  requirements,  and  human  factors 
influences. 

AIR  SCENARIO 

A  spatial  and  temporal  record  of  aerial 
activities  and  characteristics  of  an  air 
defense  "battle.  The  Air  Scenario  includes 
aircraft  tracks,  safe  corridors,  ECM,  and 
other  aircraft  and  airspace  data.  See 
also  Tactical  Scenario. 

BRANCHING 

A  term  used  in  the  SAINT  simulation  lang¬ 
uage  to  mean  the  process  "by  vhicb  TASK  nodes 
are  sequenced.  At  the  completion  of  the 
simulated  activity  at  a  TASK  node,  the 
Branching  from  that  node  determines  which 
TASK  nodes  will  "be  simulated  next. 

DATA  BASE  CONTROL 
SYSTEM 

That  part  of  the  MOPADS  software  which 
performs  all  direct  communication  with  the 
MOPADS  Data  Base.  All  information  transfer 
to  and  from  the  data  base  is  performed  by 
invoking  the  subprograms  which  make  up  the 
Data  Base  Control  System. 

DATA  SOURCE 

SPECIAL  1ST 

A  specialist  in  obtaining  and  interpreting 
Army  documentation  and  other  data  needed  to 
prepare  Air  Defense  System  Modxiles. 
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ENVIRONMENTAL 

STATE  VARIABLE 

An  element  of  an  Environmental  State 

Vector. 

ENVIRONMENTAL 

STATE  VECTOR 

An  array  of  values  representing  conditions 
or  characteristics  that  may  affect  more 
than  one  operator.  Elements  of  Environmen¬ 
tal  State  Vectors  may  change  dynamically 
during  a  MOPADS  simulation  to  represent 
changes  in  the  environment  conditions. 

'moderator  FUNCTION 

A  mathematical/logical  relationship  vhich 
alters  the  nominal  time  to  perform  an  opera¬ 
tor  activity  ( visually  a  Task  Element).  The 
nominal  time  is  ahanged  to  represent  the 
operator's  capability  to  perform  the 
activity  based  on  the  Operator's  State 
Vector.  |  - 

MOP ADS  DATA  BASE 

A  computerized  data  base  designed  specifi¬ 
cally  to  support  the  MOPADS  software.  The 
MOPADS  Data  Base  contains  Simulation  Data 
Set(s).  It  communicates  interactively  with 
MOPADS  Users  during  pre-  and  post-run  data 
specification  and  dynamically  with  the  SAIIIT 
softwpxe  during  simulation. 

MOPADS  MODELER 

An  analyst  who  will  develop  Air  Defense 
System  Modules  and  modify/ develop  the 

MOPADS  software  system. 

MO PADS  USER 

An  analyst  who  will  design  and  conduct  simu¬ 
lation  experiments  with  the  MOPADS  software. 

MSAINT 

(MOPADS/SAINT) 

The  variant  of  SAIIIT  used  in  the  MOPADS 
system.  The  standard  version  of  SAIIIT  has 
been  modified  for  MOPADS  to  permit  share¬ 
able  subnetworks  and  more  sophisticated 
interrupts.  The  terms  SAIIIT  and  MSAIHT  are 
used  interchangeably  when  no  confusion  will 
result.  See  also,  SAIIIT. 
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OPERATOR  STATE  One  element  of  an  Operator  State  Vector. 

VARIABLE 


OPERATOR  STATE  to  array  of  values  representing  the  condi- 

VECTOR  tion  and  characteristics  of  an  operator  of 

an  Air  Defense  System.  Many  values  of  the 
Operator  State  Vector  vill  change  dynamically 
during  the  course  of  a  MOPADS  simulation  to 
represent  changes  in  operator  condition. 


OPERATOR  TASK  An  operator  activity  identified  during 

weapons  system  front-end  analyses. 


SAINT  The  underlying  computer  simulation  language 

used  to  model  Air  Defense  Systems  in  Air 
Defense  System  Modules.  SAINT  is  an  acronym 
for  Systems  Analysis  of  Integrated  Networks 
of  Tasks.  It  is  a  well  documented  language 
designed  specifically  to  represent  human 
factors  aspects  of  man/nachine  systems. 

See  alsoMSAINT. 


SIMULATION  DATA  SET  The  Tactical  Scenario  plus  all  required 

simulation  initialisation  and  other  experi¬ 
mental  data  needed  to  perform  a  MOPADS 
simulation. 


SIMULATION  STATE  At  any  instant  in  time  of  a  MOPADS  simula¬ 

tion  the  Simulation  State  is  the  set  of 
values  of  all  variables  in  the  MOPADS  soft¬ 
ware  and  the  MOPADS  Data  Base. 
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SVjTEM  MODULES  See  Air  Defense  System  Modules. 


TACTICAL  SCENARIO  The  Air  Scenario  plus  specification  of 

critical  assets  and  the  air  defense  con¬ 
figuration  (number,  type  and  location  of 
weapons  and  the  command  and  control  system) . 


TACTICAL  SCENARIO 
COMPONENT 

An  element  of  a  Tactical  Scenario,  t.g. , 

If  a  Tactical  Scenario  contains  several 

Q-73 each  one  is  a  Tactical  Scenario 
Component . 

TASK 

See  Operator  Task. 

TASK  ELEMENTS 

Individual  operator  actions  vhich,  vfeen 
grouped  appropriately,  stake  up  operator 
•.asks.  Task  elements  are  usually  repre- 
ser'.  rd  by  single  SAINT  TASK  nodes  in  Air 
defense  System  Modules. 

TASK  NODE 

A  modeling  symbol  used  in  the  SAINT  simula¬ 
tion  language.  A  TASK  node  represents  an 
activity;  depending  upon  the  modeling  cir¬ 
cumstances,  a  TASK  node  may  represent  an 
individual  activity  such  as  a  Task  Element, 
or  it  stay  represent  an  aggregated  activity 
such  as  an  entire  operator  Task. 

TASK  SEQUENCING 
MODERATOR 

FUNCTION 

A  stathematical/logical  relationship  vhich 
selects  the  next  Operator  Task  vhich  an 
operator  vill  perform.  The  selection  is 
based  upon  operator  goal  seeking  character¬ 
istics. 

Additional  Terminology  and  Abbreviations 

ACN 

ADSM  Component  Number. 

ADSM 

Air  Defense  System  Module 

Reference  System 
Module 

A  code  11  directory  in  a  MOPADS  data  base 
vhich  contains  default  values  for  operator 
and  system  parameters.  It  is  the  "baseline’ 
model  for  an  air  defense  system. 

Data  but 


IDB 


ID 

Au  identifier.  ID’S  of  HCPADS  data  base 
entries  are  lists  of  integer  mashers. 

ACC 

ALSU  character  code.  A  single  character 
value  uniquely  assigned  to  a  reference 
system  module . 

DLCC 

Data  List  Character  Code.  A  one,  two,  or 
three  character  mnemonic  assigned  to  cer¬ 
tain  types  of  data  lists.  For  example, 
operator  state  vectors  have  a  DLCC  of  "OP." 

NECC 

Humber  Equivalent  of  a  Character  Code.  An 
integer  number  that  corresponds  to  s  short 
character  string.  The  capital  letters, 

A-Z,  correspond  to  the  integers  1-26  and 
the  digits  0-9  correspond  to  the  mashers 
27-36.  Thus  the  Bering  P2B  has  an  HECC  of 
162902  ("P"  corresponds  to  16,  "2"  to  29, 
and  "3"  to  02). 

DL 

Data  List.  A  list  of  values. 

DR 

Directory.  An  index  of  other  directories 
and/or  data  lists. 

I.  INTRODUCTION 


V- 


1- 0  PUP POSE 

This  document  is  *  user  manual  for  the  M0PAD6  user.  It 
introduces  all  of  the  concepts  and  procedures  needed  to  execute 
MCPADS  simulations.  The  MOP ADS  user  :t erects  vith  the  MOPADS 
software  through  the  MOPADS  User  Interface.  This  interface  stores 
and  retrieves  information  from  the  MOPADS  data  base.  Section  II 
of  this  report  explains  the  concepts  related  to  the  data  base  that 
the  MOPADS  user  must  know.  Section  III  explains  the  procedures 
needed  to  execute  MOPADS.  Such  things  as  data  cards,  Job  control 
language ,  and  input /output  files  are  discussed. 

Section  IV  explains  the  procedures  and  conventions  used  in 
issuing  commands  to  the  User  Interface.  The  MOPADS  User  Interface 
is  an  interactive  program  that  combines  aspects  of  menu  driven 
and  command  driven  orientations.  Section  IV  explains  the  basics  of 
hew  to  interact  with  this  processor. 

Sections  V  and  VI  explain  the  contents  and  purpose  of  those 
data  base  entries  that  contain  reference  data  on  air  defense  units 
and  air  scenarios,  respectively.  Detailed  discussions  on  how  to 
create  and  edit  this  information  in  contained  in  Polito  (I983a,b). 

Section  VII  explains  how  to  use  the  User  Interface  to  set  up 
MOPADS  scenarios  to  be  simulated.  Section  VIII  contains  instructions 
for  specifying  particular  parameters  for  use  during  a  simulation. 
Section  IX  explains  how  to  examine  the  statistics  produced  by  a 
MOPADS  simulation. 

2- 0  INTENDED  AJDIENCE 

MOPADS  users  and  MOPADS  modelers  should  read  this  report. 

The  language  and  level  of  detail  used  in  the  discussion  is  oriented 
to  the  MOPADS  user,  however.  Programming  and  implementation  details 
are  not  included  here.  This  information  is  discussed  in  detail  in 
MOPADS  volumes  four  and  five. 

3- 0  OTHER  READING 

The  reader  is  presumed  to  be  familiar  vith  the  MOP  DS  system. 
This  implies  that  he/she  should  have  read  the  final  report,  Polito  & 
Laughery  1983, prior  to  reading  this  document.  Specific  instructions 
about  the  details  of  the  implementation  of  the  AN/TSQ-73  and  IHAWK 
MOPADS  model  are  contained  in  Goodin  &  Polito  (1983a,b).  These 
reports  should  be  read  after  this  document. 
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II.  NOPADS  CONCEPTS 


1-0  THE  STRUCTURE  OF  THE  MOPADS  DATA  BASE 

The  MCPADS  data  base  contains  virtually  all  of  the  informa¬ 
tion  required  to  set  up ,  run,  and  review  MOPADS  simulations . 

During  initial  phases  of  development,  a  MOPADS  modeler  uses  the 
User  Interface  (Polito,  1983a)  to  create  reference  air  defense 
system  modules  (ADSM's)  and  air  scenarios  (Polito,  1983b).  This 
information  is  stored  in  the  MOPADS  data  base. 

With  the  above  building  blocks,  the  MOPADS  user  creates  simu¬ 
lation  data  sets  that  contain  a  specific  command  and  control  struc¬ 
ture  involving  (perhaps)  multiple  copies  of  the  reference  system 
modules  and  specifying  a  particular  air  scenario.  When  this  simu¬ 
lation  data  set  is  executed,  the  resulting  statistics  are  stored  in 
the  data  base.  The  MOPADS  user  can  later  examine  these  statistics 
and  select  those  he/she  desires  to  be  printed. 

The  data  base  may  contain  one  or  more  simulation  data  sets,  so 
multiple  analyses  can  hp  performed  with  one  data  base  file.  Also, 
the  data  base  files  provide  ideal  vehicles  for  archiving  MOPADS 
data,  because  the  data  base  contains  all  of  the  required  data  to 
duplicate  a  simulation. 

The  MOPADS  data  base  is  really  a  file  of  information  organized 
in  a  systematic  way.  Collections  of  related  data  are  called  "data 
lists."  Data  lists  (DL's)  can  be  thought  of  as  one  or  two-dimensional 
arrays  of  real,  integer,  or  character  data.  Collections  of  data  lists 
are  called  directories  (DR's). 

Directories  are  the  highest  level  of  organization  in  MOPADS  data 
bases,  and  they  r.re  arranged  in  a  hierarchical  fashion.  Figure  II-l 
shows  the  structure  of  the  directories  in  the  MOPADS  data  base.  The 
"DR"  in  the  boxes  indicates  a  directory  as  opposed  to  a  data  list 
(dt.ta  lists  are  not  shown  on  this  figure).  Directory  labels  are 
shewn  in  capital  letters  in  the  larger  portions  of  the  boxes.  If  the 
label  section  has  an  entry  in  lower  case  letters,  it  indicates  that 
an  arbitrary  number  of  these  directories  may  exist  with  user  assigned 
labels.  The  numbers  over  the  upper  right  corners  are  directory  codes 
which  are  discussed  in  Section  2-0  below. 

The  data  base  is  divided  into  three  main  types  of  information: 
scenarios,  reference  ADSM's,  and  simulation  data  sets.  All  of  the 
scenario  data  is  "owned"  by  a  single  directory  labelled  "SCENARIOS." 
The  contents  and  structure  of  this  information  is  discussed  in 
Section  3-1  below. 


C-15 


PREVIOUS  PAGE 
IS  ELANK 


6 


Reference  Air  Defence  System  Modules  (See  Section  3-2  below) 
are  baseline  models  of  the  air  defense  units.  At  this  writing, 
models  exist  for  the  AH/tSQ-73  and  the  IHAVK.  These  reference 
models  are  copied  into  Cimulation  Data  Sets  (Section  b-0)  to  form 
a  command  and  control  st  j-ucture  that  is  owned  by  a  "COWAUD-ABD- 
CCSTTROL"  directory.  This,  a  simulation  data  set  with  one  Battalion 
Afl/TSQ-73  and  two  I HAWK  fire  units  could  be  created  using  the 
building  blocks  in  the  REFERS!  CE-AD5M  directory. 

j 

Specific  data  concerning  a  simulation  data  set  and  the 
statistics  restilting  from  a  simulation  are  stored  in  a  "TACTICAL- 
SCEHARIO"  directory.  These  DR’s  are  discussed  in  Section  5-0, 
below.  ! 

It  is  essential  that  the  MOPADS  user  understand  the  structure 
of  the  data  base  because  many  of  the  User  Interface  commands  are 
concerned  with  editing  the  data  base  contents.  Sections  V,  VI,  VII, 
VIII, IX,  and  the  remainder  of  this  section  are  concerned  with 
teaching  the  user  what  data  is  in  the  data  base  and  how  to  mani¬ 
pulate  it.  | 

j 

2-0  DIRECTORIES  AND  DATA  LISTS 

Directories  and  data  lists  (DR’s  and  DL’s)  are  the  two  organi¬ 
zational  structures  that  comprise  a  MOPADS  data  base.  A  data  list 
is  exactly  what  its  name  implies;  it  is  an  ordered  list  of  data. 

DL's  are  physically  where  information  is  stored  in  the  data  base. 

Data  lists  may  be  designated  as  being  of  type  real,  integer,  or 
character.  Abbreviations  for  each  type  are  RDL  (real),  IDL  (integer), 
and  CDL  (character).  RDL’s  and  IDL's  may  be  one  or  two  dimensional. 
CDL's  may  have  only  one  dimension.  Every  data  list  has  a  label  which 
gives  its  name,  and  every  element  of  a  data  list  may  have  a  label. 

Furthermore,  each  user  created  directory  and  data  list  has  an 
identifier  (ID)  which  is  alist  of  integer  numbers.  The  ID’s  provide 
another  way  to  locate  and  organize  data  in  the  data  base. 

Directories  are  collections  of  data  lists  and  other  directories. 
Directories  are  said  to  "own"  DL's  and  other  directories  which  belong 
to  it.  Thus  a  hierarchy  of  directories  is  formed  in  which  each 
directory  is  owned  by  another  directory  and  which  may  own  still  other 
directories.  This  hierarchy  is  a  tree  since  no  directory  is  owned  by 
more  than  one  directory. 

Figure  II-l  is  a  schematic  of  the  MOPADS  data  base  which  shows 
the  tree  structure  of  the  hierarchy.  Various  data  lists  may  be  owned 
by  each  directory.  For  ^example,  the  operator  state  vectors  of  the 
operators  are  represented  as  data  lists  that  are  owned  by  the  system 
module  directories.  In  ;Figure  II-l,  suppose  that  there  is  a  reference 
system  module  for  the  AN/TSQ-73.  It's  directory  would  be  owned  by 


the  "REFERS!  CE-ADSM"  directory.  The  directory  for  the  AR/TSQ-73 
will  own  the  operator  etate  rector  DL's  for  each  operator  (i.e., 
the  Tactical  Director  (TD)  and  the  Tactical  Director  Assistant  (TDA)). 
The  contents  of  these  DL's  will  be  the  baseline  or  default  condi¬ 
tions  for  these  operators. 

When  a  simulation  data  set  is  constructed,  the  AN/TSQ-73 
directory  (and  all  of  the  DL's  it  owns)  will  be  copied  to  its 
appropriate  position  in  the  command  and  control  structure  (which 
descends  from  the  "OOWiAKD-AKD-CONTROL”  directory).  The  operator 
state  rector  DL's  in  these  copied  AH/TSQ-73's  will  represent  the 
operators  during  a  simulation,  and  their  contents  can  be  individually 
edited  with  the  user  interface  to  simulate  operators  with  character¬ 
istics  that  differ  from  those  of  the  default  case. 

The  MOPADS  Vaer  Interface  is  used  to  accomplish  all  of  this; 
therefore,  it  is  obvious  that  the  MOPADS  user  must  be  familiar  with 
the  structure  of  the  data  base.  Table  II-l  contains  a  description 
of  the  contents  of  each  directory  shown  in  Figure  II-l.  Directories 
are  specified  by  their  "directory  codes"  which  are  integer  numbers 
between  zero  and  thirteen.  Each  type  of  directory  has  a  unique  code. 
The  directory  codes  are  shown  in  Figure  II-l  above  the  upper  right 
corner  of  each  directory  rectangle. 

3-0  SCENARIOS  AND  REFERENCE  SYSTEM  MODULES 

3-1.  Air  Scenarios. 


Air  Scenarios  contain  a  record  of  the  movements  of  air¬ 
craft.  Air  Scenarios  are  created  by  MOPADS  modelers  using  the  pro¬ 
cedures  in  Polito  (1983a).  Each  Air  Scenario  is  defined  within  a 
coordinate  system  and  attacks  a  set  of  protected  or  critical  assets. 
The  MOPADS  modeler  specifies  the  coordinate  system  and  the  location 
of  each  critical  asset.  This  information  is  stored  in  a  "CRITICAL- 
ASSET-CONFIGURATION"  directory. 

The  MOPADS  modeler  may  then  develop  one  or  more  Air  Scenarios 
within  a  Critical  Asset  Configuration.  Each  Air  Scenario  is  a 
directory  which  contains  data  lists  representing  aircraft  movements. 
The  coordinates  of  the  aircraft  movements  are  specified  with  respect 
to  the  coordinate  system  of  the  Critical  Asset  Configuration.  Further 
more,  the  flight  paths  of  the  aircraft  in  the  Air  Scenario  represent 
an  attack  scenario  against  the  critical  assets  of  the  Critical  Asset 
Configuration.  As  will  be  seen,  when  performing  a  MOPADS  simulation, 
the  user  must  specify  which  Crit 5 cal-Asset-Configuration  directory 
and  which  Air  Scenario  directory  to  use.  Section  VI  below  describes 
the  contents  of  Air  Scenarios  and  Critical -Asset-Configuration  direc¬ 
tories  in  more  detail. 
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3-2.  Reference  Air  Defense  System  Modules 


MOPADS  modelers  develop  MSA  HIT  models  of  air  defense 
systems.  The  collection  of  such  models  represents  a  "menu"  of 
models  that  the  MOPADS  user  can  choose  from  in  creating  MOPADS 
models  of  air  defense  configurations.  The  models  that  make  up  this 
menu  are  called  Reference  System  Modules,  because  they  contain  the 
baseline  or  default  values  of  operator  and  system  parameters. 

All  Reference  Systms  Modules  belong  to  the  "REFERENCE -ADSM" 
directory  in  the  data  base  (see  Figure  II-l).  The  Reference  System 
Modules  contain  data  lists  vlth  the  following  information: 

1.  Operator  State  Vectors 

2.  Environmental  State  Vectors 

3.  Operator  Labels 

U.  MSAINT  Task  Node  Data 

5.  Resource  Data 

Ml  of  this  information  can  be  edited  with  the  user  interface  when 
the  Reference  System  Modules  are  copied  into  a  Connnand-and-Control 
structure  to  become  System  Modules  for  simulation.  Section  V 
describes  the  contents  of  System  Modules  in  more  detail. 

L-0  SIMULATION  DATA  SETS 

When  a  MOPADS  user  begins  to  create  a  MOPADS  model  of  an  air 
defense  system,  he/she  first  needs  to  ensure  that  a  MOPADS  modeler 
has  created  a  Critical  Asset  Configuration  and  at  least  one  Air 
Scenario  for  the  area  to  be  simulated.  Also,  Reference  System  Modules 
of  each  type  of  air  defense  unit  to  be  included  must  be  present  in 
the  data  base.  The  user  then  creates  a  Simulation  Data  Set  in  the 
data  base  (using  commands  in  the  User  Interface).  The  Simula. ion- 
Data-Set  directory  will  contain  a  Command-and-Control  directory.  The 
user  will  copy  the  Reference  System  Modules  Into  correct  positions 
descending  from  the  Command-and-Control  directory.  An  example  of  an 
air  defense  configuration  (showing  only  the  System  Module  directories) 
is  shown  in  Figure  II-2.  This  figure  shows  a  configuration  with  a 
Group  AN/TSQ-73  that  has  two  subordinate  Battalions.  One  of  the 
Battalions  has  two  IHAWK  batteries  and  the  other  has  only  one  IHAWK. 

The  analogy  of  the  data  base  structure  and  the  command-and-control 
structure  is  obvious:  a  unit  is  subordinate  to  another  unit  if  its 
directory  is  owned  by  the  directory  of  the  superior  unit.  Thus  by  using 
the  appropriate  User  Interface  commands,  the  user  can  construct  an 
air  defense  configuration  that  represents  the  command  hierarchy  under 
study. 


Figure  II-2.  Example  Air  Defense  Configuration. 


In  addition  to  the  air  defense  configuration,  the  Simulation- 
Data-Set  also  contains  a  Tactical-Scenario  directory  that  owns 
information  concerning  the  simulation  to  be  performed.  For  example , 
the  Tactical  Scenario  contains  a  specification  of  which  Critical 
Asset  C  nfiguration  and  which  Air  Scenarios  sire  to  be  used,  also, 
output  statistics  are  saved  in  the  Tactical  Scenarios  during  a 
simulation.  Sections  VII,  VIII,  and  IX  contain  detailed  discussions 
of  these  aspects  of  the  data  base. 
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III.  GETTING  STARTED  WITH  MOPADS 


1-0  DATA  CARDS 

The  MOPADS  software  reads  one  or  more  data  card3  whenever  it 
is  executed.  This  is  true  even  when  a  User  Interface  session  is 
run.  This  section  describes  these  initial  data  requirements. 

MOPADS  has  two  execution  modes:  "User- Interface"  and  "Run." 

The  User- Interface  mode  initiates  an  interactive  user  interface 
session.  This  allows  the  user  to  create,  edit,  and  examine  entries 
in  the  data  base.  MOPADS  must  be  executed  in  the  Run  mode,  however, 
to  perform  a  simulation.  The  usual  sequence  of  events  for  the  user 
is  as  follows: 

1.  Execute  one  or  more  User  Interface  sessions  to  create 
a  complete  Simulation  Data  Set  that  contains  all  data 
necessary  to  perform  a  simulation. 

2.  Execute  MOPADS  in  the  Run  mode  to  perform  the  simulation. 

In  this  mode ,  MOPADS  can  be  executed  as  a  batch  Job 
because  no  interactive  input  or  output  is  required. 

3.  Execute  a  User  Interface  session  to  examine  the  outputs 
from  the  simulation  performed  above. 

The  data  cards  discussed  below  must  be  placed  on  the  "MOPADS 
Batch  Input  File"  (Polito,  1983c).  The  data  cards  are  read  with 
FORTRAN  Ti  list  directed  input,  which  means  that  the  column  spacing 
in  which  the  dat*  appears  is  not  significant.  Table  II-2  shows  the 
contents  of  the  data  cards. 

For  a  User  Interface  session,  only  one  data  card  is  required. 

It  must  have  the  characters  'USER-INTERFACE'  typed  on  it.  The 
apostrophes  must  be  included.  This  is  true  of  all  of  the  data  cards 
shown  in  Table  III-l. 

To  perform  a  MOPADS  simulation,  the  first  data  card  must  be 
'RUN'  (data  card  1  in  Table  II-2).  This  must  be  followed  by  addi¬ 
tional  data  cards  to  specify  the  data  for  the  simulation.  Data  card 
2  specifies  the  name  of  the  data  base  file.  The  user  assigns  integer 
numbers  to  Simulation  Data  Sets  and  to  Tactical  Scenarios  when  they 
are  created  with  the  User  Interface.  Data  cards  3  and  b  require  the 
user  to  specify  which  of  these  are  to  be  used  in  the  simulation  since 
more  than  one  of  each  may  exist. 
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Table III-l.  MOPADS  Data  Cards. 


USER  INTERFACE  MODE:  * 

CARD 

LABEL  FIELD 

] 

DATA  FIELD 

1 

'USER-INTERFACE' 

(not  used) 

RUN  MODE: 

« 

CARD 

LABEL  FIELD 

DATA  FIELD 

1 

•RUN' 

(not  used) 

2 

'DATA  BASE  FILE  NAME' 

'file  name' 

3 

'SIMULATION  DATA  SET' 

integer  number 

It 

'TACTICAL  SCENARIO' 

integer  number 

5 

'N',  'P',  or  'C' 

'file  name' 

Repeat  card  5  as  needed 

' 

J*  Apostrophes  must  oe  typed  vherever  shoyp  in  the  data  cards. 


Finally,  when  a  Reference  System  Mouule  is  created  hy  a 
MOPADS  modeler,  it  is  necessary  to  create  an  MSAINT  network  data 
file  that  contains  MSAINT  data  cards  that  define  the  network  model. 
One  such  file  is  created  for  each  Reference  System  Module,  or.d  the 
MOPADS  software  must  have  access  to  all  if  them.  Therefore,  a 
type  5  data  card  must  be  included  for  each  Reference  System  Module 
known  to  MOPADS.  At  this  writing,  there  are  four  Reference  System 
Modules  incorporated  into  MOPADS.  A  type  5  data  cerd  must  be 
included  for  each  of  them,  even  if  not  all  types  are  represented  in 
the  Simulation  Data  Set  to  be  simulated,  e.g.,  a  data  card  must  be 
included  for  the  Group  AN/TSQ-73  even  if  the  Simulation  Data  Set  con 
tains  only  Battalion  AN/TSQ-73’ s  and  IHAWK's. 

The  label  field  for  type  $  data  cards  is  the  echo  option  for 
that  system  module  type.  The  meanings  of  the  options  are  rs  follows 

'P'  The  MSAINT  network  data  cards  are  echoed  to 

the  MOPADS  line  printer  output  file  as  they 
•  are  read.  Also,  input  error  messages  are 
printed.  'P'  stands  for  "Partial." 

* C *  In  addition  to  'P'  above,  a. formatted  summary 

of  the  MSAINT  network  is  printed.  'C'  stands 
for  "Complete .  ’’ 

'N'  No  input  data  is  echoed.  Input  errors  are 

printed,  however.  ’N'  stands  for  "None." 

Examples  of  MOPADS  data  cards  are  given  below.  Example  file 
names  are  hypothetical,  but  they  are  valid  file  names  for  Digital 
Equipment  Corporation’s  /AX  computers  with  the  v .-IS  operating  system 
on  which  MOPADS  was  developed.  Oti.er  computer  systems  may  use 
different  file  name  conventions.  Consider  the  following: 

’RUN’ 

'DATA  BASE  FILE  NAME',  ' [PRO J. MOPADS] MOPADS. DBF' 
’SIMULATION  DATA  SET',  3 
'TACTICAL  SCENARIO’,  2 
’N',  'CNTRL.NET' 

'N',  'GR0UP73.NET' 

'N',  'BATT73.NET' 

'P',  'IHAWK.NET' 

A  MOPADS  execution  an  the  Rur.  mode  is  to  be  performed.  The  MOPADS 
data  base  is  on  file  [PRGJ .MOPADS] MO PADS. DEF.  Simulation  Data  Set 
number  3  is  to  be  used  with  its  Tactical  Scenario  numbered  2. 

MOPADS  modelers  must  assign  a  number  to  Reference  System 
Modules,  and  the  type  5  data  cards  must  be  ordered  to  agree  with 
this  numbering.  For  the  present  implementation,  the  order 
shown  above  is  mandatory.  The  first  system  module  type  is  the 
Control  System  module  which  is  a  default  MSAINT  model  that  is 
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automat  ice  U/  included  in  every  simulation.  Its  function  is  to 
control  the  Simula'  ed  flights  of  aircraft  in  the  Air  Scenario. 

The  Control  Sysxem  Module  is  not  present  in  the  "REFERENCE- ADfTM '* 
directory  and  need  not  be  explicitly  copied  into  the  Simulation 
Data  Set  by  the  us^r.  The  network  data  files  for  the  Group 
AN/TSQ-73,  Battalion  AN/TSQ-73,  and  the  IHAVK  must  follow  in 
that  order. 

In  the  example  above,  the  Control  System  Module  network  *s  to 
be  found  on  file  CNTROL.NET,  and  no  echo  of  the  data  cards  are 
to  b_>  echoed.  Similarly,  the  Group  and  Battalion  AN/TSQ-73  and  the 
IHAWK  network  data  are  on  files  GR0UP73.NET,  BATT73.NET,  and 
IHAWK.NET,  respectively.  The  data  cards  for  the  IHAWK  are  to  be 
echoed.  Finally,  the  commas  that  separate  the  label  and  data 
fields  in  the  example  can  be  replaced  by  one  or  more  blanks. 

2-0  OTHER  FILES 

In  the  User  Interface  mode,  the  MOPADS  software  will  access 
several  other  files.  It  must  have  access  to  any  MOPADS  data  base 
files  which  will  be  accessed  during  the  session.  The  software 
opens  these  files  with  FORTRAN  77  OPEN  statements  and  internally 
assigns  a  unit  number  to  them.  Input  from  and  output  to  the 
User's  terminal  is  performed  with  the  MOPADS  interactive  input  and 
interactive  output  files.  These  files  must  be  associated  with  the 
User's  terminal  by  Job  control  language,  Polito  (1983c ). Furthermore , 
some  options  in  the  User  Interface  will  write  information  to  the 
MOPADS  line  printer  output  file.  This  file  must  also  be  assigned 
with  Job  control  language. 

In  the  Run  mode,  the  interactive  input  and  output  files  are  not 
used.  However,  several  others  are.  MOPADS  reads  the  system  module 
network  files  and  writes  a  compos it  network  file  on  the  MSAINT 
Network  Input  File,  The  DEC  VAX  name  assigned  to  this  file  is 
M0PADS.NET  and  it  is  assigned  by  the  software.  Similarly,  a  scratch 
file  is  created  as  a  temporary  file  which  will  be  deleted  when  execu¬ 
tion  terminates.  Finally,  if  &  trace  is  produced,  it  will  be  written 
to  a  file  named  TRACE.DAT. 
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IV.  USING  THE  USER  INTERFACE 


1- 0  WORKING  AND  REFERENCE  DATA  BASES 

With  the  User  Interface  it  is  possible  to  have  two  MOPADS  data 
base  files  open  simultaneously.  They  are  referred  to  as  the 
"working"  and  "reference"  data  bases.  The  working  data  base  file 
is  the  one  which  is  affected  by  editing  commands  issued  by  the  user. 
The  reference  data  base  is  used  only  to  store  and  retrieve  back-up 
or  reference  material. 

For  example,  when  a  MOPADS  modeler  creates  a  new  reference  air 
defense  system  module,  the  data  base  directory  for  this  model  will 
contain  parameters  specific  to  the  operators  and  environment  for  the 
air  defense  system  represented  b'y  the  model.  The  MOPADS  modeler 
should  create  this  model  in  a  data  base  file  that  contains  no  other 
information.  Then  this  data  base  file  should  be  archived  to  insure 
that  it  is  not  inadvertently  lost  or  damaged. 

When  a  MOPADS  user  desires  to  use  this  new  system  module,  he 
should  obtain  a  copy  of  the  data  base  information  in  his  own  personal 
MOPADS  data  base  file.  This  can  be  accomplished  with  the  User  Inter¬ 
face  by  designating  the  archive  file  as  the  reference  data  base  and 
the  User’s  data  base  as  the  working  data  base.  Commands  are  avail¬ 
able  to  copy  the  system  model  information  from  the  REFERENCE-ADSM 
directory  of  the  reference  data  base  to  the  REFERENCE-ADSM  directory 
of  the  vorking  data  base.  Procedures  for  performing  these  operations 
are  described  in  Polito  ( 1983a ,b) 

Normally,  only  a  working  data  base  is  opened  by  the  user, 
since  saving  and  retrieving  data  base  information  is  needed  only  to 
preserve  or  access  reference  type  data. 

2- 0  CURRENT  DIRECTORIES  AND  DATA  LISTS 

Look  now  at  Figure  II-l.  The  User  Interface  is  like  a  tele¬ 
scope  which  can  be  focused  on  one  and  only  one  directory  in  the  data 
base  at  a  time.  This  is  called  the  "current  directory,"  In  other 
words,  the  user  can  examine  the  contents  of  only  one  directory  at  a 
time.  Naturally,  commands  are  available  which  allow  the  current 
directory  to  be  changed. 

Similarly,  the  user  may  examine  and/or  change  the  contents  of 
individual  data  lists  which  belong  to  the  directories.  To  do  this, 
the  data  list  must  be  selected  as  current  also.  Therefore,  when 
using  the  User  Intel  face,  there  is  usually  a  current  directory,  and 
t..ere  may  be  a  current  data  list. 
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2-0  ID*?,  DIREd’ORY  POSn’ICN,  AND  LABELS 

D.he  Us^r  Interface  is  capable  of  printing  a  Directory  Report 
which  lists  the  characteristics  and  contents  of  the  current  direc¬ 
tory.  Figure  TV-1  shows  an  example  Directory  Report.  !he  informa¬ 
tion  at  the  top  of  the  report  pertains  to  the  current  directory. 

The  User  Message,  "MOPADS  CURRENT  DIRECTORY,”  simply  indieetes 
that  this  Directory  Report  is  being  produced  in  response  to  the 
DIRECTORY  command  which  will  be  discussed  shortly.  Next,  the  type 
of  data  base  is  printed.  This  field  will  be  either  "Working”  or 
"Reference."  The  name  of  the  data  base  file  is  printed  next,  so 
the  user  car.  always  determine  which  files  are  open  as  the  reference 
and  working  data  bases. 

Every  directory  and  data  list  has  a  label  consisting  of  up  to  Do 
characters  (25  for  data  lis\ )  and  an  ID  which  is  a  list  of  integer 
numbers.  The  label  and  ID  of  the  current  directory  are  printed  next. 
ID's  are  assigned  in  a  systematic  way  which  is  explained  in 
Tables  IV-1  and  XV-2.  *  | 
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DIRECTORY  REPORT 


USER  message: 

DATA  BASE: 

DATA  BASE  FILE: 
DIRECTORY  LABEL*. 
DIRECTORY  ID: 


MOPADS  CURRENT  DIRECTORY 

U0RKIN0 

TEST. DBF 

SIMULATION-DATA-SET 
1  1 


RANKING  CODE ( OUNED  DIRECTORIES) l 
RANKING  CODE ( OUNED  DATA  LISTS): 


INCREASING  ON  ID( 
INCREASING  ON  ID( 


1) 

1) 


OUNED  directories: 

di rector y~pos it ion: 
label: 

id:  <  l-  2)« 


DIRECTORY  POSITION! 
LABEL! 

id:  c  i-  2)* 


OUNED  DATA  LISTS  J 
DIRECTORY  POSITION! 

lapel: 

id:  <  i-  2)» 


TACTICAL-SCENARIO 

1 


C0MMAND-AND-C0NTR0L 

1 


COPY-COUNTER 

0 


Figure  TV-1.  Example  Directory  Report. 
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The  ranking  codes  for  owned  directories  and  data  lists  are  given 
next.  For  the  example  in  Figure  IV-1,  owned  directories  are  arranged 
in  increasing  order  of  the  first  word  of  their  ID's.  Ranking  can  be 
done  decreasing  instead  of  increasing,  and  if  the  ranking  is  done  on 
"ID(  0)",  then  no  ranking  is  performed.  The  ranking  codes  for  the 
directories  are  normally  not  of  interest  to  the  MOPADS  user. 

The  contents  of  the  directory  are  listed  next.  The  label  and 
ID  of  each  owned  DR  and  DL  is  given.  For  example,  the  directory 

Tactical-scenario"  has  a  two  word  id  which  is  id(i)=6  and  id(2)=i. 

In  addition,  a  number  called  the  "DIRECTORY  POSITION"  is  given  for 
each  DL  and  DR.  The  directory  position  is  a  unique  integer  number 
assigned  to  each  owned  DR  and  DL.  The  directory  position  of 
"TACTICAL  SCENARIO"  is  "1." 

The  directory  position  has  physical  meaning,  but  its  use  to 
the  MOPADS  user  is  in  specifying  a  new  current  directory.  For  example, 
if  we  desired  to  make  the  "TACTICAL  SCENARIO"  the  new  current  direc¬ 
tory,  we  could  do  it  in  one  of  three  ways: 

1.  Give  the  label  (with  no  typing  errors), 

2.  Give  the  entire  ID,  or 

3.  Give  the  dirctory  position. 

Usually,  it  is  easiest  to  specify  the  directory  position. 

Tables  IV-1  and  TV-2  contain  the  conventions  used  in  assigning 
ID’s  to  DR's  and  DL's.  For  example,  the  first  element  of  the  ID  of 
a  DR  is  the  directory  code  (see  Table  II-l).  Through  frequent  use 
and  reference  to  Tables  IV-1  and  IV-2,  the  user  will  become  familiar 
with  the  meanings  of  the  ID’s. 

L-0  SUBPROCESSES 

Figure  IV-2  is  a  schematic  of  the  organization  of  the  User 
Interface.  The  User  Interface  contains  five  subprocesses: 

1.  CREATE/EDIT  SIMULATION  DAT/.  SET 

2.  SET  UP  SIMULATION  RUN  DATA 

3.  EXAMINE  STATISTICS  . 

U.  CREATE/EDIT  SCENARIO  DATA 

5.  CREATE/EDIT  REFERENCE  SYSTEM  MODULE 

Each  subprocess  has  its  own  set  of  commands.  Subprocesses  1,  2, 
and  3  are  described  in  Sections  VII,  VIII,  and  IX  of  this  report. 

Subprocess  1*  and  5  are  used  mainly  by  MOPADS  modelers.  They 
are  described  briefly  in  Sections  VI  and  V  and  more  completely  in 
Polito  ( 1983a, b) . 

Finally,  a  set  of  basic  data  base  commands  is  available  in  all 
subprocesses.  These  commands  are  discussed  in  this  section. 
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Table  IV-1  (continued) 


12 

1 

— . — - — 

12 

2 

same  as  code  11  above 

3 

sequential  assigned 

k 

ACN 

13 

1 

13 

2 

user  assigned 

See  MOPADS  Volume  5.17  (Polito  1583d)  for  complete  descriptions 

of  the  directory  ID's  and  concents. 

Table  IV-2.  ID's  of  Selected  Data  Lists. 


DATA 

OWNER 

ID 

VALUE 

LIST 

DIRECTORY  CODES 

ELEMENT 

Run  Data 

6 

1 

1 

2 

0 

TD-TASK-DATA 

11,12 

1 

unique  number  assigned  to 
the  ADSM  character  code 
(ACC) 

2 

200U 

3 

1 

U 

0 

OP-OPERATOR- 

11,12 

1 

same  as  TD-TASK-DATA 

STATE-VECTOR 

2 

1516 

3 

operator  type 

U 

0 

1  EN-ENVIRONMENTAL-  11 ,12 

1 

same  as  TD-TASK-DATA 

STATE-VECTOR 

2 

51 

3 

1 

J» 

0 

FIELD-OF-VIEW 

12 

1 

same  as  TD-TASK-DATA 

FV 

2 

622 

3 

1 

h 

ADSM  Component  Number 

Complete  descriptions  of  all  Data  Lists  are  contained  in 

MOPADS  Volume  5-17  (Polito  1983d). 
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oxau/init 

SIMULATION  MATA 

KT 


SIMULATION  mm 
SATA 


SIAM  MX 
STATISTICS 


CMATt/COIT 
SCI  MAN IS 
SATA 


Figure  IV-2.  Organization  of  the  User  Interface. 


5-0  USER  INTERFACE  COMMAND  SYNTAX 

The  User  Interface  is  primarily  a  command  driven  processor 
that  waits  for  the  U3er  to  issue  instructions.  It  does,  however* 
have  aspects  of  menu  driven  systems  in  that  some  commands  result  in 
menus  being  presented  to  the  user.  Also,  the  command  processor 
(FFSP  described  in  Goodin  &  Polito  (1983c )) permit s  menu-like 
presentations  of  commands. 

The  regular  mode  for  entering  commands  is  shown  below. 


command, promptl»respon3el/prompt2=>response2/. . . 

The  commands  and  prompts  are  keywords  recognized  by  MOPADS.  The 
responses  are  particular  values  for  the  prompts.  For  example, 
consider  this. 


OPEN  ,FILE=M0PADS  .DBF/STATUS=0LD 


OPEN  is  the  command.  FILE  and  STATUS  are  prompts  recognized  by 
MOPADS,  and  MOPADS. DBF  and  OLD  are  values  for  the  prompts. 


Certain  prompts  for  a  command  may  have  default  values  that 
■will  be  used  if  the  prompt  is  not  entered.  In  the  example  above, 
another  prompt,  DB,  specifies  which  data  base  is  to  be  associated 
with  the  file.  Its  default  is  WORKING,  so  by  not  entering  it  on 
the  command  line,  WORKING  is  automatically  selected.  If  the  default 
value  is  not  desired,  then  the  prompt  must  be  explicitly  entered  on 
the  command  line. 

If  the  user  fails  to  enter  responses  to  all  required  prompts, 
MOPADS  will  interactively  prompt  for  them.  For  example. 


OPEN ,STATUS=OLD 

FILE [NO  DEFAULT]  *  MOPADS. DBF 


After  processing  the  OPEN  command,  MOPADS  found  that  the  required 
prompt,  FILE,  was  not  entered.  It  printed  "FILE [NO  DEFAULT] ="  to 
prompt  the  user  for  a  response.  If  the  last  non-blank  character 
on  i  command  line  is  a  dash  (-),  MOPADS  will  interactively  prompt 
for  all  unentered  prompts,  even  those  with  defaults.  For  example. 


OPEN ,STATUS=OLD  - 
DB [WORKING]  *  REFERENCE 
FILE [NO  DEFAULT]  =  MOPADS. DBF 


The  dash  caused  "DB  [WORKING]®"  to  be  printed.  The  value  between  the 
brackets  is  the  default  for  the  prompt.  The  default  can  be  selected 
by  typing  "DEF"  as  the  response.  DEF  can  also  be  entered  on  the 
command  line;  e.g. 


OPEN ,DB=DEF/STATUS=OLD/FILE® MOPADS .DBF 


The  above  demonstrates  that  the  prompt -response  groups  can  be  entered 
in  any  order. 

Also,  a  command  can  be  cancelled  at  any  time  by  typing  "CANC" 
as  a  response  or  a  prompt.  For  example, 

OPEN, CANC 
OPEN, FILE® CANC 
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Note  that  DEF  and  CANC  are  essentially  reserved  words.  The  user 
interface  treats  commas,  blanks,  and  equal  signs  as  interchangeable 
separators.  Also,  multiple  separators  are  treated  as  a  single 
separator.  This  means  that  the  commas  in  the  previous  examples 
could  be  replaced  by  any  combination  of  one  or  more  blanks  and 
commas.  The  same  is  true  of  the  equal  signs,  but  their  use  is 
recommended  to  make  the  command  lines  easy  to  read.  The  slashes 
are  required  separators  between  prompt-response  groups,  but  they 
can  be  preceded  or  followed  by  blanks  or  commas. 

A  response  may  include  separators  (i.e.,  commas,  blanks,  equal 
signs,  and  slashes)  if  it  is  enclosed  in  quote  marks  (").  For 
example,  on  some  computers  file  names  contain  embedded  blanks,  e.g.. 


OPEN  FILE= "MOPADS  DBF" 


Without  the  quote  marks  above ,  MOPADS  will  consider  MOPADS  DBF  as  two 
responses  when  only  one  is  desired.  (NOTE:  A  single  prompt  may  have 
more  than  one  response  if  the  programmer  specified  it  that  way.  In 
such  a  case,  each  response  would  be  separated  by  a  blank  or  comma.  In 
the  case  above,  however,  where  a  single  response  is  required,  the 
quote  marks  must  be  used  to  embed  the  blank  in  the  response.) 

Any  response  may  be  enclosed  in  quotes,  al thought  there  is  no 
advantage  in  doing  so  unless  a  separator  is  to  be  embedded.  Blank 
responses  can  be  entered  with  "  "  where  at  least  one  blank  appears 

between  the  quotes. 

A  generalization  of  entering  only  some  of  the  prompts  is  to 
enter  only  the  command  name: 


OPEN 

DB [WORKING] =DEF 

FILE  [NO  DEFAULT ] =MOPADS . DBF 

STATUS [OLD] =DEF 


The  User  Interface  will  prompt  for  all  responses.  This  method  can  be 
selected  if  the  user  does  not  remember  the  prompts. 


For  commands  which  the  user  issues  frequently, 
can  be  selected  by  preceding  the  command  with  "C-". 
the  prompt=  part  of  the  syntax  may  be  omitted.  For 


a  concise  mode 
In  this  case, 
example , 


& 

* 


i 

I 

$ 

I 
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C-OPEN  DEF/MOPADS . DBF 

: 

Responses  must  be  entered  il  the  same  order  as  they  are  prompted 
in  the  command-name-only  foirm.  No  response  may  be  skipped,  except 
that  if  all  remaining  responses  have  defaults  and  the  defaults  are 
desired,  then  the  command  line  may  be  terminated  (e.g.,  the  STATUS 
response  was  cr  itted  above  since  OLD  was  desired).  The  dash  works 
in  the  concise  mode  in  the  same  way  as  in  other  modes. 

The  following  rules  will  formalize  the  previous  discussion  of 
how  syntax  is  processed  by  FFSP. 

The  ccmman d-name-only  form  of  a  command  may  be  used  at  any  time 
by  typing  only  the  command  name. 

i  Blank  responses  and  responses  containing  separators  may  be 

entered  by  enclosing  them  in  quotes.  To  enter  a  blank  response 
type  "  "  (including  the  qubtes).  At  least  one  blank  must  be  entered 

i between  the  quote  marks. 

M  1 

A  command  may  be  cancelled  at  any  time  by  typing  CANC  for  any 
prompt  or  response.  You  can  not  abbreviate  CANC. 

i 

!  •  • 

The  user  may  elect  to  use  the  default  value(s)  by  typing  DEF 
for  any  response  in  a  response  list  up  to  one  field  past  the  last 
response  in  the  list. 

Slashes  (/)  must  be  used  to  separate  one  prompt-response  group 
from  another.  Blanks  or  commas  may  be  used  to  separate  all  other 
fields.  The  equal  sign  should  be  used  to  separate  prompts  from  their 
responses;  however,  it  is  not  required. 

Command  and  prompt  names  may  be  abbreviated  to  any  non-ambiguous 
string  of  characters.  For  example,  if  there  are  two  commands,  DESIGN 
and  DESCRIBE,  they  can  be  abbreviated  DESI  and  DESC  respectively.  The 
commands  may  be  abbreviated  in  longer  forms.  For  example,  the  user 
i  may  enter  DESC,  DESCR,  DESCRI,  DESCRIB,  or  DESCRIBE  for  the  command 
|  _  DESCRIBE. 

If  a  command  line  in  regular  or  concise  mode  is  ended  with  more 
than  one  dash,  the  last  dash  will  signify  to  the  system  to  prompt  the 
user  for  all  the  unentered  responses.  Other  dashes  will  then  be  con¬ 
sidered  as  part  of  a  response. 

Any  multiple  combination  of  commas  and  blanks  is  treated  as  a 
single  separator.  For  example. 


I 
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NAME  *  BILL  WOLF  and  NAME  «  BILL  f  WOLF 


are  equivalent  (here  the  response  is  u-list  of  two  character  strings). 

If  the  user  enteres  an  incorrect  response  or  misuses  the  syntax, 
FFSP  will  explain  the  error  and  prompt  interactively  for  all  remain¬ 
ing  responses. 

Concise  mode  is  signified  by  preceding  the  command  name  with 
"C-"  (without  the  quotes). 

6-0  BASIC  DATA  BASE  COMMANDS 

The  following  commands  are  available  in  all  five  subprocesses. 


1. 

CLOSE 

2. 

CURRENT 

3. 

DEPOSIT 

4. 

DIRECTORY 

5. 

EXAMINE 

6. 

HELP 

7. 

MENU 

9. 

OPEN 

9. 

PLINK 

10. 

QUIT 

11. 

SELECT 

12. 

TERMINATE 

The  prompt  and  responses  for  these  commands  are  shown  in 
Table  IV-3.  A  brief  description  of  each  command  follows. 

6-1.  CLOSE.  The  CLOSE  command  (Table  IV- 3a)  will  close  either 
the  working  or  reference  data  base.  It  can  be  used  to  switch  to  a 
new  data  base  file. 

6-2.  CURRENT.  The  CURRENT  command  (Table  IV-3b)  will  display 
label,  ID  or  both  of  the  current  directory  and/or  data  list  on 
either  data  base. 

6-3.  DEPOSIT.  DEPOSIT  (Table  IV-3C)  is  a  low  level  editing 
command  that  allows  any  element  of  the  current  data  list  to  be 
changed.  DEPOSIT  interactively  requests  element  numbers  and  new 
values . 


6-4.  DIRECTORY .  (Table  IV-3d)  shows  the  contents  (all  owned 
directories  and/or  data  lists)  of  the  current  directory  on  either 
data  base.  It  shows  the  labels,  ID's,  and  directory  positions  of  the 
contents.  This  information  is  useful  for  the  SELECT  command. 


Table  IV-3.  Basic  Data  Base  Command  Prompts 


COMMAND 

PROMPTS 

RESPONSES 

DEFAULTS  ■ 

(a)  CLOSE 

DB 

WORKING 

WORKING 

REFERENCE 

STATUS 

KEEP 

KEEP 

DELETE 

(b)  CURRENT 

DB 

WORKING 

WORKING 

REFERENCE 

DISPLAY 

LABEL 

LABEL 

ID 

ALL 

TYPE 

DIRECTORY 

DIRECTORY 

DATA-LIST 

ALL 

(c)  DEPOSIT 

DB 

WORKING 

WORKING 

REFERENCE 

( d)  DIRECTORY 

DB 

WORKING 

WORKING 

REFERENCE 

TYPE 

DIRECTORY 

DIRECTORY 

DATA-LIST 

ALL 

1 

j- 

(e)  EXAMINE 

DB 

WORKING 

WO' 

yciNG 

REFERENCE 

! 

HEADER 

NO 

NO 

YES 

DEVICE 

TERMINAL 

TERMINAL 

PRINTER 

-3 


Table  IV-3  (continued) 
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6-5.  EXAMINE.  EXAMINE  (Table  IV- 3e)  will  display  selected 
contents  of  the  current  data  list  to  the  terminal  or  to  the  MOPADS 
line  printer  output  file.  If  the  latter  is  selected,  the  data  list 
label  and  other  information  vill  also  be  printed. 

6-6.  HELP.  HELP  (Table  IV-3f)  will  print  the  prompts  and  options, 
for  the  prompts  for  the  specified  command. 

6-7.  MENU.  MENU  has  no  prompts.  It  will  print  all  command"' 
available  in  the  current  subprocess. 

6-8.  OPEN.  OPEN  (Table  IV- 3h)  will  open  a  data  base  file  as 
either  the  working  or  reference  IB.  OPEN  will  not  automatically 
close  the  current  DB.  CLOSE  must  be  used  explicitly  before  OPEN 
to  switch  DB  files.  MAXRECORD  is  the  maximum  number  of  records 
allowed  in  a  data  base  file.  It  may  not  be  needed  for  your  computer. 
Zero  implies  no  limit  on  the  file  size.  The  (MASTER-DIRECTORY)  is 
current  after  the  OPEN  command. 

6-9.  PLINK.  PLINK  (Table  IV- 3i)  will  change  the  current  direc¬ 
tory  to  the  owner  of  the  directory  which  was  current  when  PLINK  was 
issued. 

6-10.  QUIT.  QUIT  has  no  prompts.  It  causes  the  current  subprocess 
to  be  exited. 

6-11.  SELECT.  SELECT  (Table  IV-3k)  changes  the  current  directory 
or  data  list  to  one  that  is  owned  by  the  directory  that  is  current 
when  SELECT  is  issued.  The  desired  DR  or  DL  \a  selected  by  specifying 
one  (and  only  one)  of  the  following:  1-its  directory  position,  2-its 
label,  or  3-its  ID.  This  information  is  obtained  with  the  DIRECTORY 
command. 


6-1.2 .  TERMINATE.  TERMINATE  has  no  prompts.  It  will  close  all 
open  data  bases  and  terminate  execution.  This  is  the  normal  way  to 
end  a  User  Interface  session. 

6-13.  An  Annotated  Example.  Figure  IV-3  is  an  example  using  all 
the  Basic  Data  Base  Commands.  The  annotations  are  explained  below. 


§ 


V  .■ 
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The  CLOSE  e  emu  an  da  disassociates  the  cx&Tent 
data  base  file  frcm  the  MOPADS  software.  ATt^r 
dose,  MOFADS  vill  know  no  vox  king  IS.  If  STATOR 
is  specified  as  DELETE,  the  cats  base  file  vill  be 
destroyed  permanently. 

OPES  associates  the  data  base  file  V0Llt6.DE' 
to  the  software  as  the  working  DB.  STATUS*OLD 
implies  that  the  DBF  was  previously  created  as  a 
MOPADS  data  base  file.  If  STATUS*ITEW  is  specified, 
MOPADS  vill  create  a  new  MOPADS  DB  on  V0Lfc6.EBF, 
and  any  information  previously  contained  on  V0IA6.DB? 
vill  be  lost. 


The  ME/JU  command  is  always  available  to  list  the 
commands  currently  available. 

HELP  prints  information  about  a  particular  command. 

The  user  has  asked  for  information  00  the  prompts 
DISPLAY  and  TYPE.  For  DISPLAY,  MOPADS  shows  that 
it  expects  a  response  of  one  character  string  that 
must  he  one  of  the  enumerated  values  LABEL  (display 
the  label),  ID  (display  the  ID),  or  ALL  (display  both 
label  and  ID).  The  default  is  LABEL.  HELP  is 
terminated  by  entering 

Vhen  OPES  is  issued,  the  (MASTER-DIRECTORY)  becomes 
current.  The  CURKErJT  command  will  not  display  a 
directory  which  has  no  owner,  which  of  course,  the 
MASTER-DIRECTORY  does  not. 

The  DIRECTORY  command  will  always  work,  however,  even 
on  the  (MASTER-DIRECTORY).  The  contents  of  the  (MASTER- 
DIRECTORY)  are  shown. 

The  SELECT  command  makes  the  REFEREHCE-ADSM  directory 
current  by  specifying  its  directory  position  in  the 
(MASTER-DIRECTORY) . 

The  DIRECTORY  command  confirms  that  REFERS? CE-AD5M 
is  current  and  shows  the  owned  reference  ADSM's  (in 
this  case  only  one,  E-EXAMPLE). 
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Figure  IV-3.  Example  Using  Basic  Catmands, 
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Figure  IV-3.  (continued). 
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Figure  IV-3.  (continued) 
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Select  E-EXAMPLE  to  "be  current. 

Look  at  the  data  list  directory  of  E-EXAMPLE. 

This  operator  state  vector  vill  he  edited. 

The  SELECT  command  makes  the  above  operator  state 
vector  the  current  data  list.  This  is  confirmed 
vita  the  following  CURREUT  command. 

EXAMINE  specifies  that  the  data  list  is  to  he  dis¬ 
played  at  the  terminal.  The  user  wants  row  2. 
HEADER-Y  causes  the  "DATA  LIST  REPORT"  and  the 
next  6  lines  to  he  printed. 

This  display  demonstrates  that  the  basic  data  hase 
commands  are  low  level  commands;  they  know  nothing 
about  the  structure  or  contents  of  MOPADS  data  bases. 
The  operator  state  vectors  have  two  rows.  The 
second  row  contains  the  reference  values  for  each 
column.  Prior  to  a  simulation,  the  second  row  is 
copied  to  the  first  row,  which  is  dynamically 
accessed  during  the  simulation.  In  this  way,  the 
reference  or  starting  values  are  not  lost.  MOPADS 
stores  column  labels  only  for  the  first  row,  however, 
since  it  would  double  the  storage  requirement  to 
duplicate  the  labels  for  each  row.  The  "CREATE/EDIT 
REFERENCE  SYSTEM  MODULE"  subprocess  knows  all  of 
this,  so  when  a  listing  is  obtained  with  the  CHANGE 
command  in  that  subprocess,  the  labels  appear  with 
the  reference  values. 
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The  EXAMINE  command,  however,  simply  operates  on  a 
data  list  without  knowledge  of  the  meaning  of  its 
contents.  Here,  all  of  the  elements  of  row  2  appear 
to  be  (UNLABELED).  Also,  EXAMINE  prints  the  entire 
row.  Only  a  portion  of  the  listing  is  shown  here 
for  "brevity. 

Use  the  DEPOSIT  command  to  change  elements.  It  too 
is  a  low  level  c remand,  so  (row,  column)  addressing 
must  he  used. 

Elements  17,  18,  and  19  of  row  2  are  changed  (these 
are  operator  trace  parameters). 

This  demonstrates  MOPADS  response  to  input  errors. 
The  DEPOSIT  command  had  not  yet  terminated  when  the 
user  entered  the  next  EXAMINE.  MOPADS  is  expecting 
a  numeric  value  for  a  row  number.  The  free-format 
input  processor  examines  every  input  string  for  * 
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•validity  before  processing  it.  Since  "EXAMINE" 
is  not  a  valid  number,  it  prints  the  error  message 
and  requests  correct  input.  Without  this  feature, 
the  program  vould  terminate  abnormally  from  simple 
typing  errors  and  perhaps  damage  the  data  base. 

MOPADS  vill  protect  the  user  from  most  such  errors. 

CURRENT  shows  that  E-EXAMPLE  is  the  current  directory. 

FLINK  makes  the  current  directory  equal  to  the  owner 
of  the  directory  that  vas  current  when  FLINK  was  issued. 

The  CURRENT  command  confirms  that  the  REFEREE C2-ADSM 
directory  is  now  current.  Note  that  when  the  current 
directory  is  changed,  the  current  data  list  becomes 
undefined. 

QUIT  exits  the  current  subprocess  and  brings  up  the 
8ubprocess  option  menu  again. 

The  TERM  command  terminates  execution.  Selecting 
the  zero  option  on  the  subprocess  selection  menu 
accomplishes  the  same  thing. 
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V.  CONTORTS  OF  THE  REFERENCE  AIR  DEFENSE  SYSTEM  MODULES 


1-0  REFERENCE  ADSM  DATA  LISTS 

Reference  Air  Defense  System  Modules  (ADSM)  are  code  11  direc¬ 
tories.  They  contain  the  base  line  values  of  the  various  parameters 
vhich  define  the  modules.  The  User  Interface  contains  editors  for 
changing  the  information  in  these  directories.  The  same  editors  are 
available  for  modifying  working  ADSM's  (code  12  directories).  Code 
12  directories  are  simply  copies  of  the  code  11  directories. 

The  Reference  ADSM  directories  contain  the  following  data  lists: 


Operator  State  Vectors 


2.  Environmental  State 
Vector 


These  DL*s  contain  data 
that  is  unique  to  a  single 
operator .  I 


This  DL  contains! data 
which  affects  all  operators 
in  a  system  module. 


Task  Data 


This  DL  may  contain  infor¬ 
mation  for  each  MSAINT  task 
node  in  the  MSAINT  model 
of  the  system. 


System  Resources 


This  DL  contains  informa¬ 
tion  about  any  hardware 
resources  which  may  have 
been  defined  by  tie  MOPADS 
modeler. 


5.  Operator  Type  and 
Resource  Labels 


These  DL's  are  used  inter¬ 
nally  by  the  software  and 
are  of  no  concer^  to  the 


The  contents  of  these  DL's  is  discussed  briefly  below.  The 
values  for  all  of  the  parameters  discussed  in  the  following  sections 
can  be  edited  by  the  user  with  the  User  Interface.  Values  for  the 
parameters  are  not  shown  in  this  document  since  they  will  vary  from 
system  module  to  system  module.  For  example,  the  values  for  the 
IHAWK  are  given  in  Goodin  &  Polito  (1983b). 

2-0  OPERATOR  STATE  VECTOR 


Each  operator  in  an  ADSM  is  represented  by  a  separate  operator 
state  vector.  These  vectors  have  several  parts:  human  factors 
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parameters,  goal  parameters,  objective  function  parameters,  and 
display  data. 

The  htroan  factors  parameters  are  shown  in  Table  V-l.  Discus¬ 
sion  of  these  parameters  is  contained  in  Laughery  1933  and  Polito 
(1983d). Goal  parameters  are  shown  in  Table  V-2. 

Each  goal  that  the  operator  has  will  be  represented  by  fifteen 
parameters  as  shown  in  Table  V-2.  The  parameters  have  the  meanings 
shown  in  Figure  V-l  where 


ss± 

is 

GOAL-STATE-LOW-i 

— — i 

is 

PRIORITY -LOW-i 

is 

GOAL-STATE-HIGH-i 

GPi 

is 

PRI OR ITY -HI GH- i 

The  values  for  m,  M,  a.  A,  b,  and  B  are  computed  anee  when  the 
goal  parameters  are  initially  entered  by  the  MOPADS  modeler.  If 
the  MOPADS  user  desires  to  change  these  values,  they  must  be  com¬ 
puted  manually  using  the  procedures  in  Polito(l983e)  and  then 
entered  with  the  User  Interface  editor. 

Objective  Function  data  is  shown  in  Table  V-3.  These  para¬ 
meters  specify  whether  the  operator  minimizes  the  average  goal 
priority  (signified  by  a  value  of  1.0)  or  maximizes  the  average 
goal  priority  reduction  per  unit  time  (signified  by  a  value  of  2.0) 
The  number  of  goal3  that  the  operator  considers  is  also  specified. 

Finally,  the  labels  and  values  for  Display  Parameters  are 
stored  in  the  Operator  State  Vectors.  Up  to  10  display  parameters 
can  be  defined.  The  definitions  of  display  parameters  is  entirely 
up  to  the  MOPADS  modeler  except  that  parameters  't ,  3,  and  9  must  be 
as  shown  in  Table  V-U.  A  typical  set  of  display  par;  meters  is  shown 
in  the  table.  Values  must  be  specified  for  whatever  parameters  are 
defined  for  the  ADSM. 

3-0  ENVIRONMENTAL  STATE  VECTORS 

Each  Code  11  directory  has  an  Environmental  State  Vector.  The 
parameters  in  this  data  list  apply  to  everyone  in  the  system  module. 
There  are  two  types  of  data:  system  parameters  and  human  factors 
parameters. 
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Table  V-l.  Human  Factors  Parameters  in  the  Operator  State  Vectors. 


1 

CORE-TEhPERATURE 

2 

CI0-VALUE 

3 

TIME-ON-TASK 

4 

DAY5-0F-DUTY 

5 

SEARCH-DIMENSIONS 

6 

NUMBER-FIRE-UNiTS 

7 

PERCENTAGE-RECOVERY 

8 

PREVIOUS-WORK 

9 

PREVIOUS-REST 

10 

FLASH-INTENSITY 

11 

TARGET-SPEED 

12 

TARGET-TYPE 

13 

TARGET-SIZE 

14 

TARGET-COLOR 

15 

SEARCH-AREA 

16 

BINOCULAR-USAGE 

17 

SLANT-RANGE-TQ-TARGET 

18 

TARGET-TRAJECTORY 

19 

T  ARGET-BAKGRND- COMPLEXITY 

20 

NUM-BACKGROUND-CHARACTERS 

21 

MESSAGE-BACKLOG 

22 

SIGNALS-PER-MINUTE 

23 

HOURS-WORKED-PER-UEEK 

24 

DAYS-WITHOUT-SLEEP 

25 

DAYS-OF-NIGKT-DUTY 

26 

SIMULTANEOUS-TASKS 

27 

CONTRAST-RATIO 

28 

AVE-H0URS-3LEEP 

29 

OBJECTIVE-FUNCTION 

30 

GOALS-CONSIDERED 

31 

TARGET-BRIGHTNESS 

32 

NIGHTS 

33 

SKY-GROUND-RATIO 

34 

AIRCRAFT-ALTITUDE 

35 

METEOROLOGICAL-RANGE 

36 

THRESHOLD-CONTRAST 

37 

TARGET-HEIGHT 

38 

TARGET-WIDTH 

39 

TARGET-DEPTH 

40 

HORIZONTAL-RANGE 

41 

NUM-OF-RESOLUTION-EI.EM 

42 

NUM- OF- SUSPECT -ARE AS 

43 

AIRCRAFT-SPEED 

44 

FIELD-OF-VIEW 

45 

OBSERVER-OFFSET 

46 

UNUSED 

47 

DISPLAY-1 ARGET-LOCATION 

48 

TARGET-LOCATION 

49 

DISPLAY-RESOLUTION 

50 

DISPLAY-BACKGROUND-HEIGHT 

51 

DISPLAY-BACKGROUND-WIDTH 

52 

DISPLAY-BACKGROUND-DEPTH 

5  o 

Di JTANCE-TO-DISPLAY 

54 

DISPLAY-HEIGHT 

55 

DISPLAY-WIDTH 

56 

TARGET-NOISE-LEVEL 

57 

TARGET-DURATION 

58 

EXPERIENCE 

59 

SIGNAL-PROBABILITY 

oO 

REST-PERTODS 

61 

TASK-ERROR-FACTOR 

62 

TASK-ELEMENT-ERROR-FACTOR 

63 

DAYS-SINCE-PRACTICE 

Table  V-l.  (continued) 


64 

SENSE-OF-DIRECTION 

63 

SKIN-TEMPERATURE 

66 

TIME-IN-TEMPERATURE 

67 

PREVIOUS-SKIN-TEMPERATURE 

68 

X-SCREEN-CFNTER 

69 

Y -SCREEN- CENTER 

70 

SCREEN-RwNGE 

TYPE 

ELEMENT  TO  CHANGE!  C  FOR  NONE) 

Table  V-2. 

Goal  Parameters  in  the  Operator  State  Vectors. 

1 

GOAL 

2* 

LITTLE-M 

3 

BIG-M 

4 

LITTLE-A 

S 

LITTLE-B 

6 

BIfi-A 

7 

BIG-B 

8 

GOAL-STATE-LOW-1 

9 

PRIORITY-LOU-1 

10 

GOAL-STATE-LOW-2 

11 

PRIORITY-LOW-2 

12 

GOAL-STATE-HIGH-1 

13 

PRIORITY-HIGH-1 

14 

GOAL-STATE-HIGH-2 

15 

v- 

PRIORITY-HIGH-2 

Table  V-3. 

Objective  Function  Parameters  in  the  Operator  State 

Vectors. 

1  OBJECTIVE-FUNCTION 

2  NUMBER-OF-GOALS 


Goal 

Priorities 


Figure  V-l.  Goal  Parameters. 


Table  V-U.  Typical  Display  Parameters  in  the  Operator  State  Vector. 


1 

HOOKED-ITEM 

2 

VECTORS 

3 

SCREEN-ALPHA 

a 

ENGAGEMENT-MARKERS 

3 

PAIRING-LINES 

6 

MAP 

7 

SCREEN-RANGE 

8 

SCREEN-X 

9 

SCREEN-Y 

10 

UNUSED 
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Table  V-5  shews  the  system  parameters.  At  the  present  time  only 
the  following  parameters  are  used* 

7  and  8  Initial  ninth ers  of  hot  and  cold 

missile:;  at  erch  fire  section 
for  the  IHAWr 

18,19,  and  20  Tne  location  of  the  unit. 

21  The  sampling  option  for  task 

times.  Acceptable  values  are: 

1  -  unmoderated, deterministic 

task  time  (i.e., use  the  mean 
times  specified  for  the  task 
time  distribution) 

2  -  unmoderated,  stochastic  (i.e., 

random  sampled  times  j  without 
human  factors  moderators) 

!  3  -  moderated,  deterministic  (i.e., 

'  moderate  the  mean  with  human 

factors  influences)  ■ 

U  -  moderated,  stochastic  (i.e., 
moderate  the  mean  by  human 
factors  influences  and  then 
select  a  randan  sample  from 
this  new  distribution) 

Table  V-6  shows  the  human  factors  parameters  in  the  Environ¬ 
mental  State  Vector.  As  with  the  Operator  State  Vectors,  a  more 
detailed  discussion  of  these  parameters  is  contained  in  Laughery 
1983  and  Polite.  (1983d).  * 

U-0  TASK  DATA 

Certain  parameter?  apply  to  the  task  rather  than  to  the 
individual  performing  the  task.  Examples  are  the  skills  required 
to  perform  the  task  and  the  energy  output  required.  Associated 
with  each  task  is  the  vector  of  task  data  shewn  in  Table  V-7. 

Distribution  types  accepted  by  MOPADS  are  as  follows: 

1.  Constant  1 

2.  Normal 

3.  Uniform 

k.  Erlang-1  (exponential) 

5.  Lognormal 

6.  (not  used) 

7.  Beta 

8.  Gamma 
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Table  V-5.  System  Parameters  in  the  Environmental  State  Vectors. 


1  SYSTEM-MODE 

2  OPERATOR-MODE 

3  UNUSED 

4  METHOD-OF-CON7ROL 

5  WEAPONS-CONTQL-STATUS 

6  UNUSED 

7  INITIAL-AHMUNITION-HOT 

8  INITIAL-AMMUNITION-COLD 

9  UNUSED 

10  UNUSED 

11  UNUSED 

12  UNUSED 

13  UNUSED 

14  UNUSED 

15  UNUSED 

16  UNUSED 

17  UNUSED 

18  X-POSITION 

19  Y-POSITION 

20  Z-POSITION 

21  SAMPLING-OPTION 


Table  V-6.  Human  Factors  Parameters  in  the  Environmental  State 
Vectors. 


TYPE 

ELEMENT  TO  CHANGE!  0  FOR  NONE) 

1 

DRY-BULB-TEMPERATURE 

2 

RELATIVE-HUMIDITY 

3 

AIR-MOVEMENT -RATE 

4 

NOISE-LEVEL 

S 

WORKING- ARE A- ILLUMINATION 

6 

NUMBER-ON-DUTY 

■  7 

VIBRATION 

8 

AMBIENT-VAPOR-PRESSURE 

9 

NOISE-PREDICTABILITY 

Table  V-7.  TasX  Specific  Data. 


DISTRIBUTION-TYPE 

MEAN 

STANDARD-DEVIATION 

KILOCALORIES/M IN 

NUMBER-OF-BRANCHES-OUT 

STIMULUS-MODE-1  - 

STIMULUS-MODE-2 

RESPONSE-MODE 

OBSRVR-TARGET-POSITION 

CONTROL-DISTANCE 

CCNTROL-WIDTH 

NUMBER-OF-DI SPLAYS 

NUMBER-OF- ALTERNATIVES 

NUM-STM- ITEMS 

SKILL-INDEX 

SKILL-UEIGHT- 
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-  One  or  more  skills  may  "be  required  to  perform  the  task.  If 
so,  the  SKILL- IS  DEI  and  SKILL-WEIGHT  parameters  are  repented  for 
each  skill.  The  veights  are  specified  as  fractions  or  percents. 
Further  discussions  ore  found  in  Polito  l  Daughtry  3963.  Laugher? 
1983*  and. Laugher?  &  Gavron  1983. 

The  ether  human  factor  parameter?  are  discussed  in  Laugher? 

1983  4  Polito  (1983d).  The?  are  used  in  KOI ADC  in  the  same  way  as 
the  human  factors  parameters  of  the  Operator  State  Vectors. 

Finally,  the  Task  Data  may  contain  system  resource  needs.  For 
trample ,  certain  tasks  may  require  Bystem  resources  that  are  subject 
to  breakdown  or  which  may  become  unavailable  for  acme  other  reason. 
System  resources  are  specified  in  a  similar  fashion  to  skills.  In 
other  words,  a  resource  index  and  a  parameter  are  specified.  The 
current  MOPADS  models  do  not  represent  such  system  resources,  so 
they  are  not  included  in  Table  V-7.  However,  the  data  has?  and 
User  Interface  support  this  feature,  so  a  MOPADS  modeler  can  build 
or  modify  MOPADS  models  to  include  system  resources.  (NOTE:  The 
systan  resource  feature  described  here  is  entirely  independent  of 
the  reseurce  modeling  capability  built  in  to  the  MSAIHT  language. ) 

The  System  Resources  data  list  contained  in  Reference  ADSM 
directories  contains  data  on  system  resources  if  any  are  defined. 

It  is  used  in  conjunction  with  the  resources  specifications  in 
the  Task  Data.  This  data  list  is  not  used  by  the  present  MOPADS 
modeler.  See  Polito (1983d)  for  details. 


C-  56 


VI.  CONTENTS  OF  THE  SCENARIOS  DIRECTORY 


1- 0  DISCUSSION  OF  SCENARIOS 

Figure  VI-1  shews  an  expanded  view  of  the  scenarios  directory 
and  its  descendants.  A  scenario  consists  of  tvo  parts:  a  specifi¬ 
cation  of  the  coordinate  system  and  the  locations  of  critical  assets 
or  protected  sites  that  the  air  defense  system  seeks  to  protect,  and 
a  specification  of  the  aircraft  which  will  fly  through  the  area 
during  the  simulation. 

The  CRITICAL- ASSET-CONFIGURATION  (Code  13)  directories  contain 
a  ccmplet;  scenario  specification  as  discussed  shove.  More  than  one 
CRITICAL- ASSET-CONFIGURATION  can  he  contained  in  a  MOPADS  data  base 
as  indicated  in  Figure  17-1. 

Each  code  13  directory  contains  a  COORDINATE- AND- ASSET-DATA  . 
data  list  that  contains  the  definition  of  the  coordinate  system  and 
the  locations  of  all  critical  assets.  It  will  also  contain  one  or 
more  air  scenario  (code  8)  directories  that  specify  aircraft  move¬ 
ments.  Since  a  set  of  critical  aBBets  can  be  attacked  in  a  multi¬ 
tude  of  ways.  MOPADS  allows  the  modeler  to  develop  more  than  one 
air  scenario  and  store  them  in  the  data  base.  The  particular  air 
scenario  to  be  simulated  is  selected  when  a  simulation  is  set  up. 
Each  air  scenario  (code  8)  contains  separate  data  lists  for  hostile, 
friendly,  and  "other"  aircraft  tracks.  "Other"  tracks  are  those 
that  cannot  he  classified  as  friendly. 

2- 0  CRITICAL  ASSET  CONFIGURATION 

The  ID’s  of  Code  13  directories  consist  of  two  parts: 

ID(1)  -  13 

ID(2)  *  user  specified  integer 

The  CRITICAL-ASSET-CONFIGURATIONS  are  selected  by  specifying  0(2) 
when  setting  up  a  simulation. 

The  contents  of  the  COORDINATE- AND- ASSET-DATA  data  list  are 
shown  in  Table  VI-1,  The  reference  point  (elements  1,  2,  and  3) 
specify  the  origin  of  the  coordinate  system.  A  rectangular 
coordinate  system  for  a  flat  earth  is  used  by  MOPADS.  The  refer¬ 
ence  point  allows  a  particular  point  on  the  earth  to  be  specified 
by  latitude  and  longitude  to  aid  in  building  a  scenario  for  a  parti¬ 
cular  area,  and  taking  the  coordinates  of  critical  assets,  tracks, 
radars,  and  air  defense  units  from  a  terrain  map  of  the  region. 
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Figure  VI-1.  Scenarios  Portion  of  the  MOPADS  Data  Base. 
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If  the  scenario  is  not  related  to  a  particular  region,  the  coordi¬ 
nates  of  the  reference  point  may  he  Bet  to  zero. 

All  other  coordinates  are  specified  in  relation  to  the  refer¬ 
ence  point.  For  example,  critical  assets  are  located  by  specifying 
x,  y,  and  z  coordinates  using  the  reference  point  as  the  origin. 

The  x  and  y  coordinates  are  in  units  of  nautical  miles  with  positive 
x  being  east  and  positive  y  being  north.  The  z  coordinate  is  in 
units  of  feet  above  or  below  the  reference  point.  Positive  z 
is  up. 

Each  critical  asset  is  specified  by  its  coordinates  and  a  label. 
Growth  potential  is  allowed  in  the  data  base  for  differentiating 
among  critical  assets  by  type  and  possibly  by  priority. 

3-0  AIR  SCENARIOS 

Air  scenario  (code  8)  directories  contain  three  data  lists; 
one  for  each  type  of. track.  The  data  lists  are  identically  struc¬ 
tured  in  that  they  contain  the  same  types  of  information  in  the  same 
format.  Two  types  of  records  are  stored  as  shown  in  Table  VI-2. 

Aircraft  tracks  are  represented  as  piecewise  linear  segments. 
Flight  direction  and  velocity  do  not  change  along  a  segment  but  may 
vary  from  segment  to  segment.  There  is  no  limit  to  the  number  of 
segments,  so  curivilinear  motions  can  be  approximated  if  needed. 
Furthermore,  the  aircraft  motions  are  completely  specified  by  the 
information  in  these  data  lists.  Therefore,  the  current  models  do 
not  represent  evasive  actions  or  contingency  redirection  by  hostile 
aircraft. 

The  first  type  of  record  is  a  track  initiation  record.  This 
record  specifies  the  Initial  coordinates  of  the  track,  the  time  in 
minutes  from  the  beginning  of  the  simulation  when  the  track  appears, 
the  aircraft  type,  multiplicity,  and  a  Track  ID  number.  Aircraft 
type  codes  are  specified  in  Polito  (1983d),  but  they  are  currently 
not  used  by  the  models. 

Each  track  segment  is  specified  by  a  track  segment  record  with 
the  following  information:  coordinates  of  the  end  point,  and  speed 
in  knots.  Additionally,  for  hostile  tracks,  this  record  contains 
an  indication  of  whether  or  not  the  end  point  of  the  segment  is  a 
target  (critical  asset  or  air  defense  unit),  the  probability  that 
the  target  is  destroyed,  and  whether  or  not  the  aircraft  is  jamming 
along  the  segment.  Currently,  the  Jamming  information  is  not  used. 
All  of  this  data  is  specified  by  the  MOPADS  modeler  at  the  time  the 
air  scenario  is  created.  See  Polito  (1983b)  for  more  details. 

Finally,  air  scenario  directories  have  labels  assigned  by  the 
MOPADS  modeler  at  the  time  they  are  created,  and  there  ID’s  consist 
of  two  parts: 
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user  specified  integer 
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ID(1) 

ID(2) 
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The  particular  air  scenario  to  be  simulated  is  selected  by  the 
MOPADS  user  by  specifying  ID(2)  when  setting  up  a  simulation. 


Table  VI-2. 


Tra 


bk  Data. 


TRACK  INITIATION  RECORD 


Track  ID  number 
Initiation  time  (minutes 
from  start  of  simulation) 
Multiplicity 
Aircraft  type 
x-position  (n.mi.) 
y-pcsition  (n.mi.) 
z-position  (ft.) 

TRACK  SEGMENT  RECORD 

x-position  of  end  of  segment  (n.mi.) 
y-position  of  end  of  segment  (n.mi.) 
z-position  of  end  of  segment  (n.mi.) 
speed  (knots) 
end  point  a  target 
(0-no,  1-yes) 
jamming  (0-no,  1-yes) 
probability  of  destroying  target 
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VII.  CREATING  AND  EDITING  SIMULATION  DATA  SETS 


1-0  CREATE/EDIT  SIMULATION  DATA  SET  COMMANDS 

The  following  commands  are  available  in  the  CRMTE/EDIT  SIMU¬ 
LATION  DATA  SET  subprocess. 

1.  ADD 

2.  CHANGE 

3.  DELETE 
U.  INSERT 
5.  REMOVE 

The  prompts  and  responses  for  these  commands  are  shown  in  Table 
VII-1. 

The  commands  in  this  section  are  used  to  create  SIMULATION- 
DATA-SET  (code  1)  directories  (see  Figure  II-l),  COMMAKD-AND- 
CONTROL  (code  7)  directories  and  all  directories  that  descend  from 
the  code  7  directories.  Each  of  the  commands  is  discussed  in 
detail  below,  and  this  section  ends  with  an  annotated  example. 


Table  VII-1  CREATE/EDIT  SIMULATION  DATA  SET  Command  Prompts. 


COMMAND 

PROMPTS 

RESPONSES 

DEFAULTS 

(a)  ADD 

ID  NUMBER 

positive  integer 

( none ) 

(b)  CHANGE 

DAT A-LIST 

TD 

R 

OP  I  j 

EN  1 

FV  ' 

( none ) 

(c)  DELETE 

ID  NUMBER 

J  1 

positive  Integer 

ji 

( none ) 

(d)  INSERT 

ADSM 

Label  of  a 
Reference  Air 
Defense  System 
Module 

(none) 

(e)  REMOVE 

ADSM 

Label  of  a 

Working  Air 
Defense  Sys  cam 
Module 

( none ) 
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1-1.  ADD.  The  ADD  command  (Table  Vll-la)  will  create  a  new 
SIMULATION-DATA-SET  directory.  In  fact  It  also  creates  the  CQMMAND- 
AND- CONTROL  (code  7)  and  MESSAGES  (code  9)  directories.  Thus,  when 
this  command  is  executed,  an  "empty”  simulation  data  set  is  created. 
It  is  empty  in  that  it  contains  ro  copies  of  reference  ADSM's  and 
no  scenario  data. 

The  ADD  command  can  be  issued  as  often  as  needed  with  the 
restriction  only  that  the  user  assign  a  different  ID  NUMBER  to 
each  simulation  data  set.  In  this  way,  models  of  more  than  one 
command  and  control  configurations  can  be  represented  in  the  same 
data  base. 

1-2.  CHANGE.  The  CHANGE  command  (Table  Vll-lb)  is  used  to  edit 
data  lists  in  working  ADSM  (code  12)  directories.  For  example,  if 
the  command  and  control  structure  in  Figure  II-2  were  created,  each 
of  the  three  IHAWK  models  could  be  individually  edited  with  the 
CHANGE  command.  The  CHANGE  command  operates  on  the  current  direc¬ 
tory.  Therefore,  to  edit  the  structure  in  Figure  II-2,  it  would  be 
necessary  to  use  the  SELECT  and  PLINK  commands  to  make  the  desired 
IHAWK  directory  current. 

The  data  which  can  be  edited  i3  specified  by  the  prompt  DATA- 
LIST  as  follows: 


TD  - 

Task  Data 

R 

System  Resources 

OP  - 

Operator  State  Vectors 

EN  - 

Environmental  State  Vector 

FV  - 

Field  of  View 

All  of  these  were  discussed  in  Section  V  except  Field  of  View.  An 
air  defense  unit's  field  of  view  is  determined  by  the  areas  in  which 
its  radars  can  detect  aircraft  as  explained  in  Section  1-3  below. 

The  CHANGE  command  can  be  used  to  edit  the  field  of  view  data. 

1-3.  Characteristics  of  Viewers.  Each  air  defense  unit  may 
"own"  one  or  more  "viewers."  Viewers  are  usually  radars  (and  in 
the  current  implementation,  they  are  always  radars),  but  in  the  case 
of  REDEYE  or  VULCAN,  for  example,  the  viewer  might  be  a  human 
observer . 

Each  viewer  has  the  following  characteristics. 

1.  maximum  range 

2.  minimum  and  maximum  altitude 

3.  probability  of  detection 

k.  barriers  to  view 

5.  a  sector  of  interest 


The  characteristics  above  serve  to  restrict  a  viewer’s  abil¬ 
ity  to  detect  aircraft.  The  maximum  range  and  altitude  restric¬ 
tions  are  self  explanatory.  The  probability  of  detection  is  the 
probability  that  the  viewer  will  detect  an  aircraft  that  is  other¬ 
wise  in  its  field  of  view.  HOPAKS  assumes  that  once  an  aircraft 
is  detected  it  remains  detected  so  long  as  it  is  in  the  viewer's 
field  of  view. 


The  MOPADS  user  nay  specify  barriers-to-view  that  block  out 
part  of  a  viewer's  ability  to  detect  aircraft.  The  barriers 
approximate  terrain  and  other  limitations  that  preclude  a  radar  or 
observer  from  seeing  everything  within  range.  Figure  YII-1  3hows 
how  barriers  may  be  specified.  Two  types  of  barriers  may  be  speci¬ 
fied:  line  barriers  (type  l)  and  wedges  (type  2). 


PLAN  VIEW 


FIELD  OF  VIEW 


VI EWES 


LINE 

1ARRIEI  TO  VIEW 


N - SECTOR  OF  INTEREST 


SHE  VIEW 


FIELD  OF  VIEW 


"•—SHADOW  OF  BARRIER 


Figure  VII-1,  Viewers  and  Barriers-to-View, 


C-55 


In  tne  plan  view  of  Figure  VII-1,  two  line  barriers  are  shown 
to  the  east  and  southeast  of  the  viewer.  Everything  farther  away 
from  the  viewer  than  the  line  barrier  is  hidden  from  view  if  it  is 
in  the  shadow  of  the  barrier.  The  side  view  in  Figure  VII-1  demon¬ 
strates  this.  The  area  to  the  east  of  the  barrier  and  below  the 
shadow  is  hidden  from  the  viewer  (Note:  the  side  view  does  not  show 
a  complete  detail  of  the  viewer  in  the  plan  view). 

Line  'carriers  may  be  positioned  anywhere  in  the  maximum  range 
of  the  viewer  and  the  end  points  may  have  different  altitudes. 

MOPADS  assumes  a  linear  variation  of  altitude  from  one  end  of  the 
barrier  to  the  other.  Using  multiple  line  barriers,  it  is  possible 
to  create  complex  viewing  areas  that  approximate  actual  radar 
viewing  patterns. 

Wedge  barriers  are  simply  pie  shaped  sections  in  which  nothing 
is  visible.  An  example  is  shown  in  Figure  VII-1  in  the  plan  view 
to  the  vest  of  the  viewer.  The  user  specifies  the  start  and  end 
compass  headings  of  the  wedge.  . 

The  system  of  restricting  the  field  of  view  described  above  is 
not  a  perfect  representation  of  radar  vision  limits,  but  it  permits 
a  reasonable  approximation  for  modeling  purposes. 

The  IHAWK  permits  the  operators  to  specify  a  "sector  of 
interest"  which  is  a  pie  shaped  segment  of  its  vievin  ,  area.  The 
IHAWK  computer  will  automatically  process  tracks  in  this  sector.  The 
sector  of  interest  has  no  effect  on  the  radar's  ability  to  acquire 
aircraft.  It  serves  only  to  delineate  a  high  interest  area  to  the 
computer.  MOPADS  has  a  facility  to  specify  a  sector  of  interest  for 
each  viewer.  In  the  current  implementation,  the  sector  of  interest 
is  used  only  by  IHAWK. 

1-U.  DELETE.  The  DELETE  command  (Table  VII-lc)  is  used  to 
destroy  a  SIMULATION-DATA-SET  directory  and  all  of  the  information 
which  descends  from  it.  No  information  from  a  deleted  simulation 
data  set  can  be  retrieved. 

1-5*  INSERT.  The  INSERT  command  (Table  Vll-ld)  copies  a  Ref¬ 
erence  ADSM  (code  11 )  directory  to  the  current  directory.  It  is 
used  to  construct  a  command  and  control  configuration  In  a  SIMULA- 
TION-DATA-SET .  For  example,  in  order  to  create  the  configuration 
shown  in  Figure  II-2,  the  COMMAND- AND- CONTROL  directory  would  have 
been  made  current  then  an  INSERT  command  such  as 

INSERT  ADSM= "G-GROUP-AN/TSQ-73" 


would  have  been  issued.  This  would  have  copied  the  Group  AN/TSQ-73 
reference  system  module  to  the  position  shown  (i.e.,  "owned  by"  the 
COMMAND-AND-CONTROL  directory).  After  INSERT  was  complete,  the 
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COMMAND- AND- CONTROL  directory  will  still  be  current.  The  SELECT 
command  would  be  used  to  make  the  Group  working  ADSM  current,  and 
then  INSERT  would  be  issued  twice  to  create  the  two  Battalion 
AN/TSQ-73  ADSM's  which  descend  from  the  Group  ADSM.  Similar  pro¬ 
cedures  would  be  used  to  create  the  working  copies  of  the  IHAWK. 

INSERT  assigns  directory  labels  and  values  to  ID(3)  and  ID(U) 
in  a  systematic  manner  to  code  12  directories  that  it  creates. 

Recall  from  Table  IV-1  that  ID( U)  of  reference  ADSM  (code  11)  direc¬ 
tories  is  the  Basic  ACN.  This  is  a  multiple  of  1000  and  is  unique 
to  the  system  module  type.  For  example,  the  IHAWK  Basic  ACN  is  U000. 
As  code  12  directories  are  created,  the  Basic  ACN  is  incremented,  so 
the  working  IHAWK  directories  in  Figure  II-2  would  have  values  of 
ID(1*)  of  U001,  1*002,  and  1*003.  Which  copy  would  have  which  value 
depends  on  the  order  in  which  they  were  created.  In  this  way,  every 
working  ADSM  in  a  simulation  data  set  has  a  different  value  for  its 
ID(  1* ) . 


The  value  for  ID(3)  is  sequentially  assigned  within  a  directory. 
What  this  means  is  that  the  two  IHAWKs  that  belong  to  the  right  hand 
side  battalion  in  Figure  II-2  would  have  values  of  one  and  two  for 
ID( 3) .  ID( 3)  for  the  IHAWK  of  the  left  battalion  would  have  a  value 
of  one.  Likewise,  the  two  battalions  would  have  ID(3)  values  of  one 
and  two.  Their  ID(1*)  values  would  be  3001  and  3002  because  3000  is 
the  Basic  ACN  for  the  Battalion  AN/TSQ-73. 

Labels  are  created  using  the  system  module  one  character  ACC 
and  the  value  of  ID(3).  The  ACC’s  for  the  current  M0PADS  models 
are : 


G  -  Group  AN/TSQ-73 

Q  -  Battalion  AN/TSQ-73 

W  -  IHAWK 

Thus,  the  group  ADSM  in  Figure  II-2  has  label  Gl.  The  two  battalions 
have  labels  G1Q1  aud  G1Q2,  and  the  IHAWK  labels  might  be  G1Q1H1, 
G1Q2H1 ,  and  G1Q2H2.  In  other  words,  the  ACC  and  the  value  of  ID(3) 
are  appended  as  a  suffix  to  the  label  of  its  superior  unit.  In  this 
way,  each  working  ADSM  has  a  unique  label. 

1- 6.  REMOVE.  REMOVE  (Table  VH-le)  will  delete  a  working  ADSM. 
The  ADSM  to  be  deleted  is  specified  by  giving  its  label,  and  it  must 
belong  to  the  current  directory. 

2-0  ANNOTATED  EXAMPLES 

2- 1.  The  ADD,  DELETE,  INSERT,  and  REMOVE  Commands.  Figure  VII-2 
is  an  example  of  a  terminal  session.  The  annotations  are  explained 
below. 


C-67 


I1IICI0I)  UNIT 


USER  MESSAGE! 
DAT*  BASE! 

|HM8»  m 

KAMK1H0  C0r»t<0 


HOMD*  CURRENT  DIRECTORY 
NORKINg 

lit  <HASTfef-f>?RECTORT» 

OWNED  DIRECTORIES)!  INCREASING  UN 
OWNED  DATA  LISTEN  3NCREASIN0  UN 


NANKINS  COSE ( OWNED  DIRECTORIES) 
NANKINS  CODE  (OWNED  DATA  LISTEN 

ONHEB  DIRECTORIES! 


DIRECTOR!  POSITION! 

label i  „ 

IB!  I  i-  2 > - 


Ieference-absh 
2  1 


BIRCCTORT  POSITION!  2 

LABEL!  SCENARIOS 

IB!  <  1-  2>*  4  0 


SIMULATION  BATA  SET  COMMAND 


CR/CB  SIMULATION  BATA  SET  COMMAND 


EB  SIMULATION  DATA  SET  COMMAND 


BATA  BASE 
BATA  BASE 


DIRECTORT  REPORT 

AOtl  NOPADS  CURRENT  DIRECTORT 

I  WORK I  NS 

FILE!  EXAMPLE. DBF 
LABEL!  SIMULATION-DATA-SET  ^ 


!ank!n$*CODe! OWNED  DIRECTORIES)?  INCREASING  ON  IDC  I> 
RANKINS  CODE!  OWNED  DATA  LISTEN  INCREASING  ON  IB(  1) 


OWNED  DIRECTORIES! 

DIRECTORT  POSITION! 
-  LABEL!  .  II 


Command- and- control 

i 


R/EB  SIMULATION  BATA  SET  COMMAND 


-ENTER  CR/ED  SIMULATION  DATA  SET  COMMAND 


Figure  VII-2.  Examples  of  CREATE/EDIT  SIMULATIOH-DATA-SET  Caamsods 
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Figure  VII-2.  (Continued) 
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Figure  VII-2.  (Continued) 


C-70 


—ENTER  CR/EB  BIHULATXON  BATA  BET  COHNANB 

,i^L*TI0W  »A™  ,t-!-c.°-— 


“U 

EE 


WORKI  MB  ABBHtNl 
—ENTER  CR/EB  BIHUtATION  BATA  BET  COHNANB 


EBB 


B  X 


REMRT 


RECTORY 

HOPADB  CURRENT  OIRECTORT 
MORKINO 

EXAMPLE. BBF  _  _ _ 

COHNANJ-AND-CONTROL 


USER  HEBBAOEt 

BATA  BASE!  _ 

RATA  BASE  FILEt 

kIs  ytisSSB  KBRIHIH 


Ell 


DELETER 


**»!!!!!  SS  IS! 


IHliREABlN 


31 


CWHEB  B1RECTORXEBI 

directory  position: 

x.  «>. 


HEBBABEB 

0 


|Terh|| 


MTER  CR/EB  SIHULATION  BA»A  BET  COHNANB 


OFADS  EXIT 


-© 


Figure  VII-2.  (Continued) 
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Aa  part  of  the  log-on  protocol,  MOPADS  requests  the 
name  of  the  file  to  he  the  working  dat:  base.  If 
it  is  not  an  old  (previously  created)  data  base, 
the  User  Interface  creates  an  empty  MOPADS  data 
base  on  the  file. 

The  main  menu  requires  the  user  to  select  *  subpxrocess 
In  this  case,  we  select  process  one. 

The  ( MASTER-DIRECTORY )  is  current  and  it  contains  no 
simulation  data  sets. 

The  ADD  command  is  issued  twice  -  Note  the  abbre¬ 
viation  of  IDRUMBER  in  thi  second  ADD  command. 

The  DIRECTORY  command  revealB  that  Simulation  Data 
Set  number  two  (see  ID(2))  is  current.  It  was  the 
last  one  created. 

Use  PLINK  to  make  the  (MASTER-DIRECTORY)  current  again 
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DIRECTORY  continus  that  tvo  simulation  data  sets 
have  been  created.  The/  ere  numbered  one  and  tvo 
as  can  be  seen  from  their  ID(2)  values. 

DELETE  eliminates  simulation  data  set  one.  This 
is  confirmed  by  DIRECTOR/. 

Make  simulation  data  set  two  current. 

The  simulation  data  set  contains  only  the  COMMAND- 
AND- CONTROL  directory.  Make  it  current  with  SELECT. 

Copy  the  IHAWK  ADSM  to  the  COMMAND- AND-CONTROL  direc 
tory  vith  INSERT.  This  may  take  several  minutes 
depending  upon  the  system  module  being  copied  and 
the  speed  of  the  computer. 

The  position  of  the  working  ADSM  must  be  specified 
vith  respect  to  the  reference  point.  Therefore, 
the  user  must  already  have  in  mind  the  scenarios 
that  this  simulation  data  Bet  will  be  used  vith. 

DIRECTORY  shows  that  COMMAND- AND-CONTROL  is  still 
current,  and  that  the  IHAWK  has  been  copied  vith 
label  Wl.  Note  ID(3)=1  and  ID(4)=4001. 

REMOVE  deletes  the  working  ADSM  labeled  Wl  and 
DIRECTORY  confirms  that  it  has  been  removed. 

The  User  Interface  session  is  ended  vith  the 
TERMINATE  command. 


2-2.  The  CHANGE  Command.  The  CHANGE  command  has  subeditors 
to  change  each  of  the  data  lists  in  an  ADSM.  Figure  VII-3  is  on 
interactive  session  to  edit  this  data  list.  The  annotations  are 
explained  below. 


The  CHANGE  command  specifies  that  the  ’  TT>"  (task 
data)  data  list  is  to  be  edited. 


Data  is  entered  by  specifying  a  code  character  for 
the  operation  to  be  performed.  The  code  characters 
are : 

S  -  show  parameters  for  a  node 

M  -  print  the  menu  of  code  characters 

E  -  enter  data  for  a  new  node.  "E"  may 

be  used  only  once  for  any  node  to 
create  it.  This  feature  is  used 
also  in  the  CREATE/ EDIT  REFERENCE 
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Figure  VII- 3.  CHANGE  Task  Data  Example. 
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Figure  VII-3.  (Continued) 
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SYSTEM  MODULE  subprocess.  This 
subeditor  is  common  across  the 
tvo  subprocesses. 

C  -  change  parameters  for  an  existing 

node.  "C”  must  be  used  for  all 
edits  of  a  node  after  it  is 
created  vith  "E". 

Q  -  quit  editing  the  current  type  of 

task  data 

When  defaults  are  appropriate  or  au  old  value  is  to 
be  left  unchanged,  type  an  asterisk  (*)  for  the  value. 

There  are  four  types  of  data  that  may  be  specified 
for  each  node,  and  they  are  edited  separately.  The 
user  has  chosen  to  begin  vith  task  time  data. 

The  data  to  be  entered  for  task  data  are  node 
number,  distribution  type,  mean,  and  standard 
deviation.  The  input  line  creates  node  10  vith 
distribution  type  10,  mean  *  0.1  and  standard 
deviation  =  0.035-  The  values  entered  must  be 
separated  by  one  or  more  blanks  or  commas.  They 
need  not  line  up  under  the  labeled  columns.  M0PADS 
echoes  the  command  data  on  the  next  line.  The 
option  echoed  i3  the  user  option  preceded  by  "S" 

(for  Shew).  If  an  error  is  made  that  is  echoed,  the 
"S"  vill  be  replaced  by  an  "X"  (e.g.,  "XE"). 

This  line  demonstrates  that  the  spacing  between 
input  data  elements  is  not  significant. 

When  using  the  "S"  option  (e.g.,  S  10),  only  the 
node  number  is  required. 

As  a  demonstration,  the  standard  deviation  of  node 
10  is  changed  to  0.0^  and  then  back  to  0.035-  Note 
that  the  asterisks  caused  the  distribution  type  and 
the  mean  to  be  unchanged. 

The  option  menu  and  column  headings  have  been 
printed  again.  They  are  printed  every  15  lines  so 
they  vill  always  be  visible  on  most  scrolling  screen 
terminals. 

The  "C"  option  is  invalid  for  node  11  because  it 
does  not  exist.  The  "E  11  8"  line  creates  node  11 
vith  distribution  8  and  default  mean  and  standard 
deviation. 
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NOTE:  DELETING  NODES 

If  the  'C*  option  sets  the  distribution  type 
to  zero,  the  node  is  deleted.  This  is  the  only 
way  a  node  can  be  deleted.  The  "E"  option  can 
be  used  to  re-create  a  node,  but  previous  para¬ 
meter  valuer  (e.g.,  mean)  will  be  lost. 

This  capability  is  used  to  delete  node  11. 

The  "Q”  terminates  editing  of  task  time  data 
and  re-prints  the  data  type  menu. 

Begin  editing  task  specific  human  factors 
parameters.  The  10  categories  with  their 
associated  index  values  (1  through  10)  are 
printed. 

This  "C"  command  sets  parameters  5  to  one  and 
parameter  6  to  5«  Then  MOPADS  echoes  the  par  am¬ 
meter  values  for  node  10.  When  a  node  is  created 
it  automatically  has  default  values  for  each  task 
specific  parameter.  All  10  current  values  are 
printed  each  time  the  node  is  referenced.  Note 
that  in  the  echo,  parameter  5  has  value  one  and 
parameter  6  has  value  5. 

If  an  invalid  option  ("Cl6")  is  specified,  MCPADS 
prints  the  option  menu. 

Begin  editing  skill  data.  One  skill  may  be  specified 
on  each  command  line.  No  skills  are  specified  for 
a  task  by  default.  All  skill  data  must  be  specified 
explicitly  with  the  CHANGE  command. 

Skills  13  and  17  were  specified  for  node  10.  The 
command  "C  10  17  0"  deletes  skill  17  for  node  10. 

This  is  reflected  by  the  subsequent  "S  10"  command. 
Also,  existing  skills  may  have  their  weights  changed 
by  issuing  a  "c"  command  (e.g.,  "C  10  13  .8"). 

Incorrect  skills  were  entered  for  node  10,  and  the 
above  capability  was  used  to  remove  the  skills 
from  node  10  and  add  them  bo  node  lU. 

Examine  skills  for  node  lU  and  be  sure  they  are 
correct  before  moving  on  to  node  16. 

Begin  to  edit  ADSM  resource  data. 


imm 


No  ADSM  resource  data  was  specified  for  this 
example,  hut  for  completeness  resource  data  is 
entered  for  node  10  and  then  removed.  This  removal 
is  accomplished  by  issuing  a  "C"  command  vith 
resource  parameters  equal  to  zero. 

Before  exiting  from  the  CHANGE  command,  a  listing 
of  task  parameters  may  be  obtained.  It  cun  be 
printed  at  the  terminal  or  on  the  MOPADS  file  for 
non-interactive  output.  These  listings  should  be 
scrutinized  to  ensure  correct  data  entery. 

Figure  Vll-h  shovs  the  CHANGE  command  to  edit  Operator  State 
Vectors.  The  annotations  on  the  figure  are  explained  belov. 
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Three  types  of  data  are  contained  in  the  operator 
state  vectors  that  can.be  edited  vith  CHANGE. 

Begin  editing  human  factors  data.  There  are  70 
human  factors  data  elements.  The  user  can  display 
any  of  them.  Here  elements  20  to  25  are  selected. 

MOPADS  prompts  for  elements  to  be  edited  one  at  a 
time.  Both  the  label  and  value  may  be  changed 
although  normally  there  is  little  utility  in 
changing  the  label  since  the  moderator  functions 
specify  human  factors  data  by  element  number.  This 
hovever,  does  not  preclude  specialized  procedures, 
written  into  the  implementation  of  a  particular 
system  module  which  might  make  changing  a  label 
desirable. 

Use  the  asterisk  (#)  to  avoid  changing  existing 
values . 

ir 

When  done  editing,  type  zero  for  the  element  number. 
This  brings  up  the  display  option  again. 

New  values  for  elements  2h  and  25  are  shown. 

A  listing  may  be  obtained  when  done  editing  each 
data  type. 

Editing  goal  parameters  is  similar  to  editing 
human  factors  parameters  except  the  labels  may  not 
be  changed.  Also,  care  must  be  taken  in  changing 
this  data.  See  Polito  (I983e)  for  a  discussion  of 
goal  data. 
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inter  operator  mm»«  to  edikiero  to  quxt> 


tc.ccTu^|siu»  parameters  to  ebit 

B-OBJECTIVE  FUNCTION  PARAMETERS 


"  M5R  {K.ttWs'bESESNou  LINT  TO  IE!  - (|) 

■ _ LWTER  FI  RSI  AND  LAST  ELEMENTS? 0  TO  STOP)  v— * 

- ^56  Ntm-FACKOROUNI-CNANACTEM  C.OOOQOOOE40. 

KiSSase-backlob  *>.eooooo4£+o5 

23  SI6NALS-FEN-HINUTE  1.090000 

31  HOURS-WOKKEl—  FEA-UEIK  40.00000 

21  DAYS— WITHOUT— BLEEP  0. OOOOOOOEAOO 

25  aatJ-of-niomt-butt  O.OOOOOOOE+OS. 


O.OOOOOOCE400 

w.oooooo4t+o5 


TTFE  ELEMENT  TO  CMANOE?  0  FOR  NOME*  — 

■  TTFE  MEN  LABEL  AMO  VALUE?***  FOR  NO  CHANGE) 
'  TTFE  ELEMENT  TO  CHANGE?  0  FOR  HONE)  ™ 

■  TTFE  NEW  LABEL  AMS  VALUE?***  FOR  NO  CHANOEI 

'  TTFE  ELEMENT  TO  CHANBE?  0  FOR  NONE)  _ 

WHICH  ELEMENTS  WOULP  YOU  LIKE  TO  SEE 
-SWTEk  FIRST  AHB  LAST  ELEMENTSCO  TO  STOF) 


- - -  JO  NUP-PACKBROUHP- CHARACTERS  0. 

21  HESSAG s— BACKLOG  .  0. 

22  SI8NALS-FEL-M1NUTE  1 

31  HOURS— WORKE  I»-F  EH- WEEK  4 

34  1iAT5-UITH0Ut— SLEEP  1 

25  »ATS-0?-NlSHT-BUTT*  1 

DTTFE  ELEMENT  TO  CHANGE?  0  FOR  HONE) 

WHICH  ELEMENT*  WOULP  YOU  LIKE  TO  SEE 
ENTER  FIRST  AN*  LAST  ELEMENTSCO  TO  STOP! 

T  SO  TOU  WANT  A  LIST1N0T  * 

n1 

-SELECT  DESIRE*  FARAMETERS  TO  EDIT 
t-SUIY 

1— HUMAN  FACTORS  PARAMETERS 
3-SOAL  pakahSters 
J«OkJECTlVE  FUNCTION  FARAMETERS 

I)flc6  EL?MEll?SIl35uL?TrOO  LIKE  TO  SEE 
- .INTER  FIR2I  AHB  LAST  ELEMENTSCO  TO  STOP! 


0.00O<>00PE400 

o.oooooooltoo 


0.0000000x401 
1.000000 
40.00006 

1.000006 — r  [  k  ) 
i.oooooc^ii- — \VJ 

— <D 


1  2??Vle-n 

«  lJttle-a 
S  LITTLS-B 

TTFE  ELEMENT  TO  CHANGE?  0  FOR  HONE) 

JHHS  hWOJm 


1.000000 

-0.1000000E41I 

0.00000001400 

0.0000000x400 

0.0000000x400 


E3f;; 


’ll  GOAL 

a 

IF  LITTLE-A 

20  LITTLE-* 

5i  Hfcf 

21  OOAL-STATE-tOW-; 

24  TKX  ORlTY-LQ*-i 

23  aOAL-STATE-LDtf-2 

2*  FRIORITY-LDy-2 
27  iDAL-STATE-HJBH-I 
7 ft  7*IPftTTt-HJ6H-l 
27  GOAL-S7ATI-HI0H-2 
37  ffcJORITY-HlBH-2 


? -HOC OP o 

oTiooooSoc41 1 

0.3125H2E-G2 
2*747437 
0.0000000*400 
O.OOOO0OOE4O0 
0 • 000 0000 £40 7 
30.00007 
7.000000 
10.00000 
0*60070001407 
0. 090000 OE 4 07 
6.0000G90E+00 
0 .00 0000 OE 400 


E41 1  V— ' 


TIP*  ELEMENT  TO  CHANGE?  0  FOR  HONE) 

S  M^TnsTO  Tg£lTor, 

loj 

BO  TOU  WANT  A  LISTING? 

Select  desired  parameters  to  edit 

?-oun 

S-MUMAN  factors  parameters 

J-GpAL  PARAMETERS 

I-objaCtivl  Function  parameters 


Figure  VII-U.  CHANGE  Operator  Data  Example. 
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THERE  ARE  .2  ELEMENTS  ....  „„ 

M  ttlrfcWlfW  Ht.WH.I'TS'iT.f. 

J  1  OBJECTIVE-FUNCTION  i’SSSSS?. 

2  NUMBER-OP— GOALS  2.000000 

TYPE  ELEMENT  TO  CHANGE:  0  FOR  NONE) 

|  TYPE  NEU  LABEL  AND  VALUE  (  *  *  *  FOR  NO  CHANGE) 

'TYPE  ELEMENT  TO  CNANOE<  0  FOR  NOME) 

.suits  miwhh  iM’fuv.'Un 

»  1  OBJECTIVE-FUNCTION  2.000000 

2  NUHBER-OF-SUAL*  2.000000 

TYPE  ELEMENT  TO  CHANGES  0  FOR  NONE) 

Silts  ftHWISk?  SES»t!5S,l"T?:tT0.. 

DO  YOU  WANT  A  LISTING? 

TERMINAL(T)  DR  LINE  PRINTERSP)  ■«  . 


DATA  LIST  REPORT 


— <D 


USER  message: 
DATA  BASE  FILES 
DATA  LIST  LA) ELI 
DATA  LIST  in: 
DATA  LIST  TYPES 


OPERATOR-1 

V0L46.DPF 

OP-OPERATOR-STATE-VECTOR 
<  1-  3)-  5  ISIS 

REAL 


DATA  LIST  contents: 


1.000000 

O.OOOOOOOE+00 

32.00000 

%  °.mi 

144.0000 
147.0000 
O.OOOOOOOE400 
O.OOOOOOGE4O0 
0.00 OOOOOE 400 
O.OOOOOOOE400 
0 . OOOOOOGE400 
O.OOOOOOOE400 
O.OOOOOOOE400 
0 .00000  OOE  4  00 
0 • OOOOOOOE400 
0. 1000000E421 
0. 1000000E+21 
0.1000000E421 
O.OOOOOOGE400 
0 • O 000000 E4 00 
Q.OOOOOOOE4O0 
0. OOOOOOOE400 
O.OOOOOOOE4DO 
O.OOOOOOGE400 
O.OOOOOOOE400 
O.OOOOOOOE400 
O.OOOOOOOE400 
0.0000000£400 
O.DOOOOOOE400 
O.OOOOOOOE400 
37.00000 
1.000000 
O.OOOOOOOE400 
O.OOOOOOOE40Q 
1.000000 
O.OOOOOOOE400 


OPERATOR-TYPE  ^ 
OPERATOR-ID  » 
POINTER-TO-HF-TASK-PATA 

P8I8?igr?8=gS5HF5Sg??E5ER 

POINTER-TO-DISPLAY-INFO 

POINTER-TO-T ASK-STACK 

UNUSED 

UNUSED 

UNUSED 

UNUSED 

UNUSED 

UNUSED 

UNUSED 

UNUSED 

UNUSED 

START-TRACE-TINE 

END-TRACE-TINE 

TRACE- INCREMENT 

UNUSED 

UNUSED 

UNUSED 

UNUSED 

UNUSED 

UNUSED 

UNUSED 

UNUSED 

UNU5E0 

UKU5ED 

UNUSED  _ _ „ 

UNUSED  /l^N 

CORE-TEMPER ATUF.E  1 1  9) 

CIP-VALUE  \X£J 

T1HE-0N-TASK 

DAYS-OF-DUTY 

SEARCH-DIMENSIONS 

NUMBER-FIRE-UNITS 


Figure  VII— 1».  (Continued) 
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100.0000 

6.0000000E400 

10.00000 

0<6o888SSe40G 
0.0000000|400 
O.OOOOOOOE400 
0 • OOOOOOOE400 
340.0000 
0 . OOOOOO0E4O0 
O.OOOOOOOE400 
O.OOOOOOOE400 
1.000000 
O.OOOOOOOE400 
0.O00OO00E400 
1.000000 
40.00000 
1.000000 
1.000000 
1.000000 
1.000000 
6.000000 
1.000000 

i:8SlllI 

2.000006 
1.000000 
O.OOOOOOOE400 
4.000000 
1.000000 
O.OOOOOOOE400 
O.OOOOOOOE400 
0.O00O000E400 
O.OOOOOOOE400 
1.000000 
1.000000 
O.OOOOOOOE400 
340.0000 
O.OOOOOOOE400 
0.O000O00E400 
S. 000000. 
O.OOOOOO0E400 
340.0000 

8: 1888888 
0.1000000 
1.330000 
1.000000 
1.000000 
40.00000 
0 . OOOOOOOE40Q 
20.00006 
O.OOOOOOOE400 
1.000000 
0.0000000E400 

O.O0OOOOOE4O0 
O.OOOOOOOE400 
O.OOOOOOOE400 
0 . OOOOOOOE400 
1.000000 
-0.1000000E411 
O.OOOOOOOE40D 
C . OOOOOOOE4DO 
O.OODOOO0E4O0 
1.000000 
1.000000 
0 . OOOOOOOE400 
O.OOOOOO0E4O0 
O.OOOOOOOE400 
O.OOOOOOOE40D 
1.000000 
1.000000 
3.000000 

3.000006 

3.000006 

33.00000 
0. 1000000E411 
0.3:23 J4JE-02 
3.B4B437 

0 • OOOOOOOE400 
0.5000000E406 
O.OOOOOOOE400 
30.00000 
6.000000 
10.00000 
O.OOOOOOOE400 
0.0000000£406 

o.ooooooot+oo 
O.OOOOOOOE400 
-3 . 000000 
0 • OOOOOOOE400 
O.OOOOOOOE400 
O.OOOOOOOE400 
0. OOOOOOOE400 
0.0000000t405 

0. 0000000E400 
O.OOOOOOOE400 
O.OO0OOCOE4OS 
O.OOOOOOOE409 
0 • OOQQO00E4O0 


PERCENTASS-RECDVEItV 

PREVIOUS-WORK 

PREVIOUS-RES? 

target-type 

TARGET-SIZE 

TARGET-COLOR 

Umcculak-ubabe 

SLANT-RANBE-TO-TARGET 

tarEIJ-saWInd^cohplexity 

NUff-BACKGROUNt—CHARACTERS 

.MESS  AGE- BACKLOG 

SIGNALB-PER-Himnt 

HOURS-UORKEWER-UEES 

BAYB-UITHOUT-SLEEP 

DAY  B-OP-HI BUT— PUTT 

SIHlftTANEOUS-TAIKS 


OBJECTIVE— FUNCTION 

f2gfc?^8g!5SfSIEs 

NIGHTS 

SKY— BROUND— RATIO 
AIRCRAFT -ALTITUDE 
HETEOROLOGXCAL-kANGE 
T  HREBHOL  D-CONTRAST 
TARGET-HEIGHT 
TARGET -UIDTH 
TARGET-DEPTH 
HORIZOHT  AL— RAHGE 
Nim-OF-RESOLUTIOW-ELEH 
NUR— OF— SUSPECT -AREAS 
AIRCRAFT-SPEED 
FIELD— OF— VIEH 
OBSERVER-OFFSET 
UNUSED 

niEwrtssJ?R;lDCftT10H 

DISPLAY— RESOLUTION 

DISPLAY— BACKOROUND-DEFTH 
DIBTAHCE-TO-DISPLAY 
DISPLAY— HE  1*3  HT 
DISPLAY-UIDTH 
T ARGET-HO I SE-LEVEL 

target-duration 

1 I BNAL-Pr8d ABILITY 
REST-PERIODS 
T ASK-ERROk-F ACTOR 
TASK-ELEHENT -ERROR-FACTOR 
X-SCREEN- CENTER 
V-SCREER-CENTIR 

SCREEN-RANGE  _ 

GOAL  ^  " 

little-a  . 

BIO— D 

OOAL-STATE-LOU-I 
PRIORITV-LOh-1 
OOAL— ST  ATt-LON— 2 
priority-lov-2 

OOAL— STATE— HIBH— | 
PRIORITY— HIGH— I 
GOAL— STATE— HI  Dh-2 
PRI0RITY-HI6H-2 
GOAL 

LITTLE-H 
BID— H 
LITTLE-A 
‘  LITTLE-D 
BIG— A 
BIG— D 

GOAL-STATE-LOV-1 

PRIORITY— LON- 2 
GOAL— ST  ATE— HIBH-  1 
PRIORITV-HIGH-1  _ 
GDAL-STATE-HIGH-2 
PRIORITY-HIGH-2 
GOAL 

LITTLE-H 

BJS-H 

LITTLE-A 

LITTLE-D 

BIG— A 

BI6-D 

GOAL  — STATE-LON-  1 
PRIOR IT v- LON- 1 

OOAL-STATc-LON-2 
PRIORITY- LON-2 


Figure  VII— U.  (Continued) 
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The  operator  state  vectors  are  stored  vith  pointers 
to  the  various  types  of  data  (i.e.,  human  factors, 
goal  parameters ,  etc.)*  See  @  .  Thus,  the  human 
factors  data  begins  at  element  32  Qg . 

To  find  human  factor  parameter  6,  for  example, 
compute  its  index  as  follova:  32+6-1  *  37. 

Column  37  of  the  operator  state  vector  is  human 
factors  parameter  6. 

Similarly,  the  goal  parameters  start  at  column  97, 
and  the  objective  function  data  begins  at 
column  lb2,^). 

Finally,  the  display  and  task  stack  information 
begins  at  columns  lM»> and  147, respectively 
These  data  cannot  be  edited  because  they  change 
dynamically  during  simulations. 


Figure  VI1-5  is  an  example  of  editing  the  Environmental  State 
Vector  for  the  reference  ADSM. 
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The  environmental  state  vector  contains  system  and 
human  factors  data.  Editing  is  performed  in  the 
same  vay  as  for  human  factor  parameters  in  the 
operator  state  vectors. 

The  listing  is  also  in  the  same  format  as  the  opera¬ 
tor  state  jectors.  System  parametezs  begin  at 
element  2 .(UJL  and  human  factors  data  Btarts  at 
element  23,^j) 


■  "  ■ !  r i  ■  t :  itiir  phawrrtes 


TO  UXt 


IU.UI  ixsias*  rasaniiir.*  l 


q 

o 


THEM  ARI 

IMS  - 


21  ELEHINTS _ _ 

'WSM  2*HkS?liJez!flT0P> 


<D 


0 

O 

0 

0 


rriTiMroi 

4  MtTMotv-o»-c>rrrn. 

■  wapons-contoc-  status 

TYPE  ELEMENT  T*  CHANCE (  •  EM  HOME) 

TYPE  MEN  LABU.  AN>  VALUE  CP*  PM  NS  CHANEL > 
TYPE  ELEMENT  TS  CUANSEI  •  PM  NONE) 

vhtcn  tunm  howls  too  like  ts  in 

ENTES  riAST  AMS  LAI i  ELEMENTS!*  Tl'  STOP) 

SO  TOO  UANT  A  LISTINOT 


1.0009)0 

C.OOOOOOff+OO 

O.OOCOOOti+OO 

1.000090 

2.000000 


Figure  VII-5.  CHANGE  En-vironaental  Data  Example. 
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CHANGE  system  resources  vere  not  defined  for  the  example,  "but 
an  example  of  defining  such  data  is  given  in  Figure  VTI- 6.  The  data 
vhich  may  he  specified  for  a  resource  is : 

1.  Resource  Number 

2.  Number  of  Units  Available 

3.  Mean  Time  Between  Failures  (MTBF)  (hrs) 

1*.  Mean  Time  to  Repair  (MTR)  (hrs) 

5.  Use  Code  ( O-non-exclusive  use,  1-may  be 
used  by  only  one  operator) 

6.  Status  (l- green,  2-ember,  3- red) 

Editing  is  performed  in  the  same  way  as  for  Task  data  and  the  listing 
(not  shown)  is  formatted  in  the  Bame  way. 


ichange  rtn-LHi.n 

“ — BmnrTBTrrnx^OM-uti.  use  t  to  (elect 

DEFAULT  Ok  LEAVE  UNCHANGED 

FI*  OFTIONS.  (ELECT  TO  SET  THU  HENU 

oftxdn:  (-*how  FAHAfirrm.  h-hemu.  e-inter  data  row  new  resource 

r-CHAHSE  EXXRTINO  RESOURCE.  O-CUTT  REROULCEt 
OntOH  RESOURCE  N0.-UH2T(  HTDF  HTk  CODE  STATUE 


I  1 


(L__ 
gSEj|r 


100, 

nrr 


*■ 


ZD 


o 

I  |l£l 

ci r 


S 


DIO 


■RADIO 


s 


EL- (UNUSED) 

RESOURCE  NOT  DEFINED 
SO  YOU  WANT  A  LISTING 

-ENTER  CR/XS  ADEN  C DA HAND 


EOO.O 

(5.00 

O.OOOOt 


0.0000 

o.oueo 

0.0000(400 


Figure  VII-6.  CHANGE  System  Resource  Data  Example. 


Figure  VII-7  shows  the  CHANGE  command  to  edit  the  field  of  view 
information.  The  annotations  are  explained  below. 


The  DIRECTORY  AND  SELECT  commands  are  used  to 
make  the  IHAVK  directory  VI  current. 


The  CHANGE  command  indicates  that  the  FIELD- 
OF-VIEW  (FV)  data  list  is  to  he  edited. 


A  menu  of  viwer  editing  options  is  given. 
Select  "it"  to  create  viewers. 


Viewers  have  a  user  specified  number.  In  this 
case,  "1". 
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i  v«yra*  *»o rro* 


HIICTdT  HMIt 


no  mtiMct 


MCPAD3  CURRENT  DIRECTOR? 

WORKINf 

EXAMPLE. B»F 


PILES  EXAMPLE. B1F 

LAkELt  COMMAN^- AND- CONTROL 


RANKINS  CoiSitMIKB  DIRECTORIES)! 
RANKINS  COBEIONNEB  DATA  LISTS) I 


OWNED  DIRECTORIES! 

BIRECTORT  POSITIONS 
LABELS 

IBS  l  »*  4)« 

BIRECTORT  POSITIONS 
I-  4>m 


1NCREAS1H0  OH  IDS  4> 
INCREASINS  ON  IBS  2) 


MESSASES 

6 


-ENTER  Cft/ED  tlHULATXON  DATA  SET  COtMAN* 
"TTZI  mm  .... - -  . .  — — ■ 

^%W;Ctj;fF-*TI0N  DATA  SET  COMMAND 

‘'■fintH  twi  tfclHu  VALUES.  USE  TO  SELECT 
DEFAULT  OR  LEAVE  A  VALUE  UNCHANGED 


1- SHOV  VIEWER  PARAMETERS 

2- EDIT  VIEWER  PARAMETERS 

3- DELETE  VIEWER 


2-EDIT  VIEWER 

•ERflUtt* 

WHICH  VIEWER? 
ENTER  BATAf't* 
STAT  RAN8C 


4-CREATC  VIEWER 
3-EDIT  BARRIERS 
A-QUlt 


PROS  X-POB 


SECT- -ETART  SECT-END _  I 

-cu*p  o.oooetoo  iso.  ^  | 

NO.  STAT  RANOE  WIN _ MAX  PROS  X-POS 

t  1  43.0  O.OOOEtOO  0.1 50E +04  O.TOO  I0s7~ 

_ SECT-START  SECT-END _ 

O.OOOETOO  340. 
m  OKST/N)? 


1-SHOW  VIEWER  parameters 

i:p^T^1viIwER*RMETER* 

pi  EHTER  NUMBER 
rn  whic»Tvieher?  [ 

“*  EMTElf  DATAt**’  TO  SELECT  DEFAULT) 
NO.  STAT  RANGE  MIN  MAX 


4- CREATE  VIEWER 


MAX _ PRO!  X-POS _ T-POS _ Z-POS 

2?0E+05  O.tOO  O.OOOETOO  O.OOOETOO  O.OOOETOO 


SECT-START  SECT-ENB 


OOETOO  340. 


Figure  VII-7.  Annotated  £  ample  of  the  CHANGE . Command  Viewers. 
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Figure  VII-7.  (Continued) 


CHANGE  prints  a  default  viewer ;the  parameters  are: 
STAT  1:  viewing 


RANGE 

MIN 


X-POS ,Y-P0S 
Z-POS 

SECT-START, 

SECT-END 


2 :  not  viewing 

range  in  nautical  miles 
minimum  viewing  altitude  in  feet 
above  or  below  the  viewer 
altitude  (see  Z-POS) 
maximum  viewing  altitude  above 
or  below  the  viewer  altitude 
probability  the  viewer  sees 
on  aii^cr’-ft 

coordinates  of  the  viewer  position. 
X  and  | Y  are  in  nautical  miles, 

Z  is  feet 

start  and  end  true  compass  azimuth 
of  the!  sector  of  interest  in 
decimal  degrees 


After  data  is  entered,  MOPADS  prints  the  new  values 
and  asks  if  they  are  ok. 


I  In  jU  . 


oZ 


te  a*.  .  -a*  .-** 


© 

© 

© 
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A  second  viewer  is  created.  Note  that  the  data 
need  not  he  typed  exactly  under  the  headings 
printed  by  MOPADS.  The  only  requirement  is 
that  the  data  be  typed  in  the  correct  order  and 
the  data  fields  be  separated  by  blanks  or  commas. 

Existing  viewers  can  be  edited. 

Edit  the  second  viewer. 


MOPADS  prints  a  viewer  editing  menu  and  asks  for 
a  selection.  "C"  indicates  that  a  barrier  will 
be  defined. 


Data  entry  for  barriers  is  similar  to  that  for 
viewers.  The  data  are: 


TYPE  - 

HI 

THETA1  - 

HI 


R2.THETA2,  - 
H2 


barrier  type 

1-  line  barrier 

2-  wedge  barrier 
distance  of  one  end  of  a  lino 
barrier  from  the  viewer  (in 
nautical  miles) 

true  compass  azimuth  from  the 
viewer  to  the  end  of  the  barrier 
(in  decimal  degrees) 
altitude  above  or  below  the 
viewer  altitude  of  the  end  of 
the  barrier  (in  feet) 
analogous  to  Rl.THETAl,  a_.d  HI 
for  the  other  end  of  a  line  barrier 


See  (13)  for  wedge  barriers 


Add  a  wedge  barrier  now. 


For  a  wedge  barrier,  only  THETA1  and  THETA2  are 
significant.  The  barrier  is  from  THETA1  clockwise 
to  THETA2. 


"A"  shows  all  defined  barriers.  Note  that  each  has 
been  assigned  a  number  by  MOPADS., 


Barriers  are  edited  in  the  same  way  as  viewers. 


Asterisks  need  not  be  entered  explicitly  if 
remaining  fields  on  a  line  are  to  be  defaulted. 


Delete  the  second  barrier. 


C-90 


MOPADS  may  renumber  the  barriers  after  deletion. 
For  example,  if  there  are  five  barriers,  and  the 
third  one  is  deleted,  MOPADS  will  renumber  ihe 
remaining  barriers  one  through  four. 

"E"  returns  to  the  viewer  menu. 

"l"  prints  selected  viewers.  Note  the  new  field 
on  the  second  line,  "BAR”.  This  is  the  number 
of  barriers  for  the  viewer. 


Delete  viewer  number  1. 

Note  that  the  viewers  are  not  renumbered, 
number  two  remains. 


Viewer 


A  listing  of  all  viewers  and  barriers  can  be  printed 
at  the  terminal  or  on  the  MOPADS  line  printer 
output  file. 


The  column  of  "l"'s  next  to  the  barrier  information 
indicates  that  this  information  is  for  barrier 
number  on  e. 


VIII.  SETTING  UP  SIMULATION  RUN  DATA 


1-0  DATA  REQUIREMENTS 

1-1.  Run  Data. 

There  are  nine  data  elements  that  must  "be  specified  prior 
to  a  MOPADS  simulation.  The  first  two  are  the  critical  asset  con¬ 
figuration  and  the  air  scenario.  Recall  that  a  simulation  data  set 
is  constructed  with  a  particular  critical  asset  configuration  in  mind. 

The  critical  asset  configuration  is  specified  with  the  second 
element  of  the  ID,  1D(2),  of  the  particular  CRmCAL-ASSET-CONFlGU- 
RATION  directory  to  be  used.  See  Figure  II-l  and  Table  IV-2. 
Similarly,  the  air  scenario  is  specified  by  the  second  element, 

ID(2),  of  the  ID  of  the  appi  riate  directory.  See  Figure  II-l  and 
Table  IV-2  again.  Naturally,  the  air  scenario  must  belong  to  the 
specified  critical  asset  configuration  directory. 

The  number  of  simulation  runs  must  also  be  specified.  Each 
run  is  a  replication  of  the  entire  simulation.  Multiple  runs  are 
performed  to  obtain  aggregate  statistics  over  several  replications. 
Replications  of  a  MOPADS  simulation  should  not  be  done  unless  some 
of  the  system  modules  have  stochastic  sampling  options  (see  Section 
V,  3-0).  If  only  deterministic  sampling  options  are  used,  then  only 
one  run  should  be  performed. 

The  start  and  end  times  of  the  simulation  must  also  be  speci¬ 
fied.  These  are  twenty  four  hour  military  times  from  0000  to  2359. 

MSAINT  will  produce  an  event  trace  if  requested.  The  start 
and  end  mms  must  be  specified  for  the  trace.  Zero  nan  numbers  will 
suppress  the  trace.  Event  traces  are  frequently  interesting,  but 
they  produce  a  very  great  deal  of  output,  so  the  user  should  not 
select  a  trace  unless  it  is  needed  for  some  purpose. 

MOPADS  uses  a  separate  random  number  stream  for  each  working 
system  module  so  the  task  times  generated  for  each  module  are  inde¬ 
pendent.  In  addition,  it  employs  an  initialization  scheme  to  ensure 
that  Task  times  are  independent  from  run  to  run.  This  is  accom¬ 
plished  by  employing  a  special  initialization  stream  from  which  the 
other  random  number  streams  are  initialized.  MOPADS  has  a  default 
seed  for  this  initialization  stream,  but  the  user  may  specify  a  seed 
for  this  stream  if  desired. 

Finally,  the  track  update  interval  can  be  specified.  This  is 
the  maximum  time,  in  seconds,  between  re-c amputation  of  the  aircraft 
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coordinates.  The  default  is  15  seconds.  Note  that  this  is  the  maxi¬ 
mum  time.  As  a  practical  matter,  MSAINT  will  usually  compute  air¬ 
craft  coordinates  every  second  or  so.  The  update  interval  is  pro¬ 
vided  as  a  back-up  to  ensure  that,  in  unusual  cases,  the  tracks  are 
updated  frequently. 

1- 2.  Fire  Unit  to  Critical  Asset  Assignments. 

Normally,  fire  units  are  positioned  in  order  to  protect  one 
or  more  critical  assets,  and  the  critical  assets  are  "assigned"  to 
the  fire  unit.  The  critical  assets  are  defined  in  the  CRIT1CAL- 
ASSET-CONFIGURATION  directory.  They  must  be  assigned  to  fire  units 
before  a  simulation.  Critical  assets  which  are  not  assigned  to  fire 
units  are  not  protected.  Normally  only  one  site  is  assigned  to  an 
IHAWK  battery. 

2-0  SET  UP  SIMULATION  RUN  DATA  COMMANDS- 

The  commands  for  this  subprocess  are  shown  in  Table  VIII-1. 

They  are  described  briefly  below. 

2- 1.  ADD.  The  ADD  command  is  used  to  create  a  new  "TACTICAL- 
SCENARIO"  directory.  These  directories  are  numbered  by  the  user. 

The  response  to  the  prompt  TSNUMBER  becomes  the  number  of  the  tac¬ 
tical  scenario.  A  SIMULATION-DATA-SET  directory  must  be  current  in 
order  to  issue  this  command. 


2-2.  DELETE.  The  DELETE  command  will  delete  a  "TACTICAL- 
SCENARIO"  directory  from  the  current  simulation  data  set.  It  will 
also  destroy  all  information  owned  by  the  tactical  scenario. 

2-3.  EDIT.  EDIT  is  used  to  add  or  change  run  data  for  the 
tactical  scenario.  The  data  which  can  be  changed  with  EDIT  was 
described  in  Section  1-0  above. 

2-U.  USE.  USE  provides  an  easy  way  to  make  a  simulation  data 
set  current.  The  response  to  the  prompt  IDNUMBER  is  the  simulation 
data  set  that  will  became  the  curren^  directory. 

3-0  AN  ANNOTATED  EXAMPLE 


The  annotations  are  Figure  VIII-1  are  explained  below. 


Select  the  CREATE/EDIT  SIMULATION  RUN/DATA  subprocess  from 
the  main  menu. 


© 

© 


The  USE  command  attempts  to  make  simulation  data  set 
number  one  current.  Since  no  such  simulation  data  set 
exists,  an  error  message  is  printed. 


Simulation  data  set  number  two  is  made  current. 


Table  VIII-1.  SET  UP  SIMULATION  RUN  DATA  Commands 


COMMAND 

PROMPTS 

RESPONSES 

DEFAULTS 

(a) 

ADD 

TSNUMBER 

positive  integer 

— 

(b) 

DELETE 

TSNUMBER 

positive  integer 

— 

(c) 

EDIT 

TSNUMBER 

positive  integer 

— 

(d) 

USE 

IDNUMBER 

positive  integer 

— 

© 

© 
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The  ADD  command  creates  Tactical  Scenario  number  two 
in  the  current  simulation  data  set.  All  parameters  in 
the  tactical  scenario  assume  default  or  null  values. 

The  EDIT  command  must  be  used  to  specify  oth!er  values. 

EDIT  enters  the  editor. 

Title  information  can  be  specified  for  each  tactical 
scenario.  Here  only  a  single  line  of  title  information 
is  entered.  Type  "/QUIT"  when  done  entering  the  title. 


Note  the  repeat  of  the  question. 

DO  YOU  WANT  TO  EDIT  THE  TITLE  (Y/N)? 


This  editor  will  always  permit  the  user  to  go  back  and 
re-edit  data  Just  edited.  This  is  true  of  all  data 
editing  features  in  this  editor. 


© 

© 


The  title  editor  permits  lines  of  text  to  be  replaced. 

It  does  not  support  character  editing  within  a  line.  i 

When  done  editing  the  title,  the  editor  moves  on  to  run 
data.  It  prints  the  current  values  of  the  run  parameters 
and  prompts  for  changes. 

Pairs  of  numbers  represent  element  numbers  and  new  values. 
For  example,  "U  0915"  changes  the  start  time  to  0915- 
Note  the  re-prompt  for  editing  run  data  again.  If  the 
response  to  this  question  was  YES,  the  new  values  of  the 
run  parameters  would  be  printed. 
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Figure  VIH-1.  Examples  of  SET  UP  SIMULATIOH  P.UB  DATA  Ccnmnnda. 
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Figure  VIT1-1.  (Continued) 


Begin  to  edit  fire  unit  to  critical  asset  assignments. 


Hi)  The  editor  prints  the  ACN’s  of  all  sir  defense  units  i'. 
the  simulation  data  set. 


®Iext  the  editor  asks  vfticb  asset  assignments  the  user 
wants  to  see.  The  asset  number,  asset  label,  and  the 
ACS  it  is  assigned  to  are  printed.  Since  this  tactical 
scenario  has  not  been  edited  before,  there  are  no 
assignments . 

©Assign  asset  one  to  be  protected  by  the  unit  with 
ACH  1*001. 


Print  the  assignments  again  to  verify  the  new  assignment. 
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Tactical  scenarios  contain  the  output  statistics  pro¬ 
duced  by  M0PAD6  when  they  are  simulated.  In  order  ,  to 
ensure  that  such  information  is  not  inadvertently 
destroyed,  MOPADS  will  allow  a  Tactical  Scenario  to  be 
used  only  once. 

The  DELETE  command  destroys  the  specified  tactical 
scenario. 

QUIT  causes  a  return  to  the  main  menu. 
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IX.  EXAMINING  STATISTICS 


1-0  MOPADS  STATISTICS 

1-1.  Run  Statistics. 

MOPADS  can  collect  and  report  two  broad  categories  of 
statistics:  Run  and  Summary.  Run  statistics  are  data  collected  for 
one  run  (or  iteration)  only.  An  example  might  be  the  average  number 
cf  active  tracks.  If  more  than  one  run  is  performed,  a  value  for 
this  statistic  would  be  reported  for  each  run,  and  each  of  the  values 
would  be  independent .  In  other  words ,  the  average  number  of  aircraft 
in  run  two  has  no  effect  on  the  average  in  run  three. 

Summary  statistics,  on  the  other  hand,  are  collected  over  runs. 
An  example  is  the  percent  down  time  of  an  IHAWK  launcher.  Each  run 
produces  one  observation  of  this  statistic.  The  observations  are 
averaged,  and  the  average  down  tine  is  reported  once  at  the  end  of 
all  runs.  Summary  statistics,  then,  obtain  one  observation  for  each 
run  and  report  the  mean,  standard  deviation,  etc.  of  those  obser¬ 
vations.  Summary  statistics  are  discussed  in  Section  1-2  below. 

Run  statistics  are  discussed  in  this  section. 

1-1 . a  Task  Node  Run  Statistics  and  Histograms. 

MSAIHT  task  nodes  can  be  designated  as  sta¬ 
tistics  nodes.  If  a  node  is  so  specified,  MSAIHT  will  automati¬ 
cally  collect  and  report  various  statistics.  The  report  has 
headings  as  shown  below. 


TASK  STAT  COLL  NO. 

NODE  LABEL  TYPE  TIME  AVERAGE  STD  DEV  MINIMUM  MAXIMUM  08S 


TASK  NODE  -  The  number  cf  tee  task  node. 

LABEL  -  The  label  of  the  task  node. 

STAT  TYPE  -  One  of  the  following: 

FIR  -  record  the  time  that  the  task  is 
performed  for  the  first  time  in 
a  run. 

ALL  -  record  the  time  that  the  task  is 
performed  for  each  time  it  is 
performed  in  a  run. 
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BET  -  record  the  time  interval  between 
performance  of  the  task. 

XKT  -  record  the  time  interval  to  the 
time  the  task  is  performed  from 
a  previous  time.  This  option 
requires  that  the  previous  time 
be  set  in  an  operator's  attributes 
by  another  node. 

BUM  -  record  the  number  of  times  the  task 
node  is  performed. 

COLL  TIME  -  The  time  that  the  observation  is  collected.  It 

is  one  of  the  following: 


REL 

- 

when  the  node  is  release. 

STA 

- 

when  the  task  node 

Is 

started. 

COM 

- 

when  the  task  node 

is 

completed. 

CLR 

- 

when  the  task  node 

is 

cleared. 

AVERAGE, 
STD  DEV 

MINIMUM, 

MAXIMUM 


As  an  example,  if  ST  AT  TIME  is  BET  and  COLL  TIM  is 
COM  .then  the  node  would  record  the  time  between 
completions  of  the  task  node. 

-  The  sample  average  and  standard  deviation  of  all 
the  observations  taken  during  a  run. 

-  The  smallest  and  largest  observation. 


BO.OBS  -  The  number  of  observations. 

1-1. b  Run  Statistics  Based  on  Observations  (User). 


MSAINT  allows  the  modeler  to  collect  any  statistics 
of  his  choosing  by  providing  subprograms  that  are  called  from 
modeler  written  FORTRAK  code.  An  example  might  be  the  number  of 
missiles  fired  per  salvo.  A  value  is  collected  each  time  a  salve 
is  fired,  and  these  observations  are  averaged.  The  report  headings 
are  shown  below. 


LABEL  MEAN  STD  DEV  MINIMUM  MAXIMUM  NO.OBS 


Each  such  statistic  is  assigned  a  label  which  is  printed  under  the 
LABEL  heading.  The  other  headings  are  the  same  as  explained  above. 
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1-1.  e 

Time  persistent  statistics  arfe  similar  to  statistics 
based  on  observation  except  that  they  are  averaged  over  time.  An 
example  is  the  average  number  of  active  tracks.  The  number  of  active 
tracks  persists  until  another  track  enters  the  simulation  or  until 
a  track  completes  or  is  destoryed.  The  average  is  computed  by 
weighting  each  observation  by  the  length  of  time  that  is  persists. 

The  headings  are  shown  below. 


LABEL  MEAN  STD  DEV  MINIMUM  MAXIMUM  INTERVAL 


Time  Persistent  Statistics 


All  of  the  headings  are  the  same  as  described  earlier  except 
INTERVAL.  IHTIKVAL  is  the  length  of  time  in  minutes  over  which  the 
statistics  were  collected.  Normally  this  is  the  length  of  time  that 
the  simulation  was  run. 


1-1. d  Histograms  (User) 


User  histograms  are  similar  to  task  node  histograms, 
except  that  the  modeler  must  record  observations  by  making  sub¬ 
program  calls  to  the  appropriate  statistics  collection  programs. 


1-1. e  Count  Statistics. 


Count  statistics  are  simply  a  record  of  the  number 
of  times  that  a  particular  event  occurred  during  a  run.  An  example 
is  shown  below. 


COUNT 


NUMBER  OF  SITES  DESTROYED  X 

NUMBER  OF  SITES  ATTACKED  1 

NUM  HOST  TRACKS  NOT  DEST  ,  0  . 

TOTAL  NUMB  HOSTILE  TRACKS  3 

TOTAL  NUMB  FRIEND, TRACKS  i 

TOTAL  NUMB  OTHER  TRACKS  1 

NUMB  HOSTILE  A/C  DEST,  2 

NUMB  FRIENDLY  A/C  DEST  0 

NUMB  OTHER  A/C  BEST  1 

NUMB  HOST  TRACKS  ATTACKED  2 

NUMB  FRND  TRACKS  ATTACKED  0 

NUMB  OTHR  TRACKS  ATTACKED  1 

****************************************** 
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1-1 . f  Operator  Taak  Fraction  Statistics. 

MOPADS  reports  the  fraction  (in  percent)  of  the  time 
that  each  operator  spends  In  each  operator  task.  (Note  that  opera¬ 
tor  tasks  are  not  the  same  as  task  nodes;  consult  Goodin  &  Polito 
( 1983a ,b)  for  the  AN/TSQ-73  and  the  IHAWK  task  lists.  An  example 
for  an  IHAWK  Fire  Control  Operator  (FCO)  is  shown  below. 


OPERATOR  TASK  FRACTION  STATISTICS  {RUN 

AIR  DEFENSE  UNIT  tWl 

OPERATOR  SFCO-A 


TASK 


7 

8 
9 

11 

12 

13 

14 


TINE 

PERCENT 

48.251 

7.588 

7.773 

5.717 

2.121 

3.337 

25.214 


The  MOPADS  document  Goodin  &  Polito  (1983b)  must  be  consulted  to 
identify  tasks  7,  8,  etc.  Tasks  which  are  not  performed  are  not 
reported. 


1-2.  .  Summary  Statistics.  f 

1-2 . a  SAINT  Resource  Utilization  Statistics. 

If  a  system  module  uses  SAINT  resources,  then 
their  utilizations  will  be  available  asisummary  statistics.  The 
report  headings  are  shown  below.  | 


R£J 

NUM  LABEL 


AVERAGE  STD  MINIMUM  MAXIMUM 
PCT_BUSY  DEV  PCT_BUSY  PCT_BUSY_ 


RES  NUM 


The  number  assigned  to  the  resource. 


LABEL 


The  resource  label. 


AVERAGE  PCT  -  If  more  than  one  run  is  performed,  this  is  the 
BUSY  average  of  the  percent  busy  for  each  run. 
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STD  DEV  -  The  standard  deviation  of  the  percent  busy. 

MAXIMUM  PCT  -  The  largest  and  smallest  percent  busy  observed. 

BUSY, MINIMUM 
PCT  BUSY 


1-2  .b 


;istics. 


MSAINT  also  automatically  provides  summary 
statistics  of  the  TASK  NODE  HUN  statistics.  It  does  this  vith  the 
following  procedure.  At  the  end  of  each  run, the  average  value  is  com¬ 
puted  for  each  statistic  discussed  in  Section  1-1. a  above.  If 
more  than  one  run  is  performed,  the.  computed  averages  are  them 
selves  averaged  to  obtain  a  sample  mean  of  the  sample  means.  This 
data  is  reported  as  shown  below. 


TASK  STAT  COLL  AVERAGE  OF  STD  DEV  OF  MINIMUM  MAXIMUM  NO. 

NODE  LABEL  TYPE  TIME  AVERAGE  AVERAGES  AVERAGE  AVERAGE  OBS 


The  headings  have  the  same  meanings  ns  In  Section  1-1. a  except  as 
shown  below. 

AVERAGE  OF 
AVERAGE 

STD  DEV  OF 
AVERAGE 

MINIMUM  AVER¬ 
AGE,  MAXIMUM 
AVERAGE 

NO. OBS  -  The  number  of  runs. 


2-0  EXAMINE  STATISTICS  COMMANDS 

The  commands  for  the  subprocess  are  shown  in  Table  IX-1. 

They  are  described  briefly  below. 

2-1.  DISPLAY.  DISPLAY  prints  the  labels  of  all  system  modules 
and/or  operators  in  the  simulation  data  set.  If  ADSM's  is  speci¬ 
fied  as  YES,  the  labels  of  all  system  modules  is  printed. 

If  OPERATORS  is  specified  as  an  ACC,  the  labels  of  the  opera¬ 
tors  for  that  system  module  type  are  printed.  If  OPERATORS  is 
then  all  operator  labels  art  printed.  Finally,  a  blank 
response  signifies  no  operator  labels  are  to  be  printed. 


An  estimate  of  the  mean  of  the  sample  mean. 

An  estimate  of  the  standard  deviation  of  the 
sample  mean. 

The  larges  and  smallest  sample  mean  obseived. 
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Table  IX-1.  Examine  Statistics  Canaan ds 


COMMAND 

PROMPTS 

1  RESPONSES 

DEFAULTS 

a)  DISPLAY 

ADSM's 

No 

Yes 

No 

OPERATORS 

blank, *, or 
an  ACC 

blank 

b)  PRINT 

none 

none 

none 

c)  SHOW 

none 

none 

none 

d)  USE 

SIMULATION- 

positive 

The  current 

DATA-SET 

integer 

simulation 
data  set 

TACTICAL- 

positive 

The  curren* 

SCENARIO 

integer 

tactical 

scenario 

RUN 

■positive 
integer  or 
"SUMMARY" 

SUMMARY 

2-2.  PRIST.  Print  displays  statitics.  It  has  no  prompts. 

Use  of  the  FRIOT  command  is  discussed  in  Section  3-0  below. 

2-3.  SHOW.  The  SHOW  command  prints  the  current  simulation 
data  set,  tactical  scenario  and  run.  See  USE  below. 

2-U.  USE.  The  MOPADS  User  must  specify  which  set  of  statis¬ 
tics  he/she  desires  to  examine.  This  is  done  by  specifying  a  simu¬ 
lation  data  set,  a  tactical  scenario,  and  a  run  (or  SWWARY).  The 
USE  command  accomplishes  this.  The  prompts  for  USE  are  updated 
each  time  they  are  given.  This  means  that  they  remember  their  last 
value.  Thus,  the  User  can  change  runs  by  specifying  only  the  new 
run  number,  e.g. ,  USE,  RUN=2. 
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3-0  ORGANIZATION  OF  THE  PRINT  COMMAND 
3-1.  The  Main  Category  Menu. 

The  PRINT  command  provides  a  flexible  scheme  for 
selectively  printing  statistics.  For  example,  all  statistics  for 
a  particular  system  module  can  be  printed,  or  the  Operator  Task 
Fraction  statistics  for  all  IHAWK  Tactical  Control  Officers  (TCO's) 
can  be  selected.  This  is  accomplished  by  selecting  a  main  and  a 
secondary  statistics  category.  The  main  category  menu  is  shown 
below. 


MAIN  CATEGORY  MENU  J 

-  -  EXIT  PRINT  COMMAND 

1  -  AIR  DEFENSE  UNIT 

2  -  OPERATORS 

3  CONTROL  SYSTEH 

A  -  SAINT  TASK  NODE  STATISTICS 

B  -  SAINT  RESOURCE  STATISTICS 

C  -  SAINT  JSER  STATISTICS 

D  -  MOPADS  COUNT  STATISTICS 

E  -  OPERATOR  TASK  FRACTION  STATISTICS 

F  -  MOPADS  TRACE 

*  -  TOGGLE  DISPLAY  DEVICE(T) 


The  option  determines  where  statistics  are  printed. 
Another  menu  appeers  that  permits  the  user  to  select  from 
T-terminal,  P-printer,  or  B-both.  Option  3,  CONTROL  SYSTEM,  refers 
to  the  control  system  module  that  is  implicitly  present  in  every 
simulation  data  set.  A  small  MSAINT  network  forms  this  module 
which  manages  the  flight  paths  of  aircraft. 


Seconder 


Menus. 


When  a  category  is  selected,  a  secondary  category 

menu  is  printed.  As  an  example,  if  main  category  1  -  AIR  DEFENSE 
UNIT  is  selected,  the  following  secondary  menu  appears. 

MAIN  CATEGORY  SELECTIONS  AIR  DEFENSE  UNIT 

SECONDARY  CATEGORY  MENU: 

—  -  EXIT  PRINT  COMMAND 

0  -  RETURN  TO  MAIN  CATEGORY  MENU 

+  -  ALL  STATISITICSCEXCEPT  TRACE) 

A  -  SAINT  TASK  NODE  STATISTICS 
B  -  SAINT  RESOURCE  STATISTICS 
C  -  SAINT  USER  STATISTICS 
D  -  MOPADS  COUNT  STATISTICS 
E  -  OPERATOR  TASK  FRACTION  STATISITICS 
*  -  TOGGLE  DISPLAY  DEVICE(B) 

ENTER  SELECTION  7  FOR  MENU) 


ENTER  LABEL  OF  AIR  DEFENSE  UNITCT  FOR  MENU) 
E.G.  G1Q2H3  OR  Q  (FOR  ALL  TYPE  Q'S) 
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The  user  selected  D  -  MOPADS  COUNT  statistics.  He  is  now 
prompted  for  an  air  defense  unit  specification.  The  label  of  one 
air  defense  urlt  can  be  given  (e.g. ,  G1Q2H3)  in  which  case  the 
count  statistics  for  that  unit  will  be  printed.  If  an  ACC  is  given 
(e.g.,  Q) ,  then  the  count  statistics  for  all  type  "Q"  system 
modules  in  the  simulation  data  Bet  will  be  Printed. 

After  printing  statistics,  the  secondary  menu  vill  be  printed 
again  for  another  selection.  The  user  can  return  to  the  main  menu 
with  option  "0”  or  exit  the  PRINT  command  with  option 

l*-0  THE  MOPADS  TRACE 

Ho  trace  has  been  implemented  in  the  User  Interface.  A  main 
category  selection  is  available  for  TRACE,  and  if  it  is  selected  a 
secondary  menu  will  be  printed.  If  a  secondary  selection  is  made, 
a  message  will  be  printed  indicating  that  this  feature  is  not  avail¬ 
able  yet.  It  has  been  included  for  future  growth. 

An  event  trace  is  available,  however.  The  runs  to  be  traced 
are  specified  in  the  Tactical  Scenario  by  the  User,  and  a  trace  is 
produced  on  the  MOPADS  trace  file.  (TRACE.DAT  for  DEC  VAX  imple¬ 
mentations.)  An  exerpt  of  the  trace  is  shown  below. 

ttttSDETAILED  ITERATION  OUTPUT  FOR  RUN  NUMBER  1  SSStt 

0PERAT0RM0DULE  MODULE  TASK  TASK  TASK  SIMULATION 

TYPE  ID  TYPE  NO.  LABEL  POINT  TIME _ 


1 

2 

3 

4 

5 

6 
7 
0 
0 
0 
0 
7 
7 


5 

S 

4 

4 

3 

3 

2 

2 

1 

1 


3001 

3 

31 

CREATETD 

RELEASE 

3001 

3 

32 

CREATTDA 

RELEASE 

4001 

4 

45 

SOURCTCO 

RELEASE 

4001 

4 

46 

SOURCTCA 

RELEASE 

4001 

4 

47 

SOURCASO 

RELEASE 

4001 

4 

48 

SQURCFCA 

RELEASE 

4001 

4 

4? 

SOURCFCB 

RELEASE 

0 

1 

1 

STARTTR 

RELEASE 

.  0 

1 

5 

CNTRLTIM 

RELEASE 

.  o 

1 

1 

STARTTR 

COMPLETE 

.  0 

1 

2 

INITIATE 

RELEASE 

4001 

4 

4? 

SOURCFCB 

COMPLETE 

4001 

4 

40 

TASKSEDW 

RELEASE 

4001 

4 

48 

SQURCFCA 

COMPLETE 

4001 

4 

40 

T  ASKSEQW 

RELEASE 

4001 

4 

47 

SOURCASO 

COMPLETE 

4001 

4 

40 

T  ASKSEQW 

RELEASE 

4001 

4 

46 

SOURCTCA 

COMPLETE 

4001 

4 

40 

TASKSEOW 

RELEASE 

4001 

4 

45 

SOURCTCO 

COMPLETE 

4001 

4 

40 

TASKSEOW 

RELEASE 

3001 

3 

32 

CREATTDA 

COMPLETE 

3001 

3 

30 

TASKSEQ 

RELEASE 

3001 

3 

31 

CREATETD 

COMPLETE 

3001 

3001 

3001 

3 

I 

30 

iff 

T  ASKSEQ 
ThPKSEQ 
TSEL-TD 

RELEASE 

COMPLETE 

RELEASE 

0.000000E+00 

O.OOOOOOE+OO 

O.OOOOOOE+OO 

O.OOOOOOE+OO 

O.OOOOOOE+OO 

O.OOOOOOE+OO 

O.OOOOOOE+OO 

O.OOOOOOE+OO 

O.OOOOOOE+OO 

O.OOOOOOE+OO 

O.OOOOOOE+OO 

O.OOOOOOE+OO 

O.OOOOOOE+OO 

O.OOOOOOE+OO 

O.OOOOOOE+OO 

O.OOOOOOE+OO 

O.OOOOOOE+OO 

O.OOOOOOE+OO 

O.OOOOOOE+OO 

O.OOOOOOE+OO 

O.OOOOOOE+OO 

O.OOOOOOE+OO 

O.OOOOOOE+OO 

O.OOOOOOE+OO 

O.OOOOOOE+OO 

O.OOOOOOE+OO 

O.OOOOOOE+OO 


■?' *"  ".'.TO- 
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The  headings  have  the  following  meanings. 


OPERATOR  TYPE  - 


Operator  type  as 
Modules  ^hen  the 
were  created 


assigned  by  the  MOPADS 
reference  system  modules 
For  the  current  implementation 


the  values  indicate: 


0 

1 

2 


control  system  module  event 

Battalion  AN/TSQ-73  Tactical  Director 

Battalioh  AN/TSQ-73  Tactical  Director 
Assistant 


3  -  IHAWK  Tactical  Control  Officer 
,  I 

k  -  IHAWK  Tactical  Control  Assistant 

5  -  IHAWK  Azimuth  Speed  Operator 

I 

6  -  IHAWK  Fire  Control  Operator  A 

7  -  IHAWK  Fire  Control  Operator  B 

i  8  -  Group  AN/TSQ-73  Tactical  Director  1 

( 

9  -  Group  AN/TSQ-73  Tactical  Director  2 

MODULE  ID  -  The  unique  number  assigned  to  a  system  module 

in  the  simulation  data  set.  The  ACN  of  the 
component.  See  Section  VII,  2-5. 


MODULE  TYPE  -  The  type  of  component: 

1  -  Control  System  Module 

2  -  Group  AN/TSQ-73 


• 

3  -  Battalion  AN/TSQ-73 

U  -  IHAWK 

TASK  NO. 

- 

Task  node  number. 

TASK  xjABEL 

- 

Label  of  the  task  node. 

TASK  POINT 

— 

One  of  RELEASE,  START,  COMPLETE,  or  CLEAR.  • 

If  RELEASE  and  START  time  are  the  same,  only 
RELEASE  will  be  printed. 

SIMULATION 

TIME 

The  simulated  time  in  minutes.  If  in  the  tac¬ 
tical  scenario,  the  user  specified  a  start 
time  of  0915,  then  the  simulation  time  will 
begin  at  555*  (9x60+15). 

A  typical  MOPADS  run  processes  a  great  many  events,  so  the 
trace  can  be  very  long.  MOPADS  wilil.  execute  faster  and  consume 
less  disk  file  space  if  a  trace  is  hot  produced. 


C-107 


I 


^.isrjwT»rT< 


T*C^17  c;.scr»r  <"  R. 


flP 


BitIWTOWai 


5-0  AN  ANNOTATED  EXAMPLE 


The  following  is  an  annotated  example  of  a  terminal  session 
with  the  EXAMINE  STATISTICS  subprocess. 


© 

© 

© 

© 

© 

© 

© 

© 

© 

© 

© 

© 
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Select  the  EXAMINE  STATISTICS  subprocess  from  the 
User  Interface  main  menu. 

The  User  Interface  prints  the  current  simulation 
data  set,  tactical  scenario,  or  run  to  remind  the 
user  that  they  have  not  been  specified. 

The  USE  command  selects  simulation  data  set  2, 
tactical  scenario  1,  and  run  1.  This  is  confirmed 
with  the  SHOW  command. 

The  display  command  will  pr^nt  system  module  and 
operator  labels. 

The  control  system  module  is  always  present  with 
label  CONTROL.  Two  other  system  modules  were  also 
in  this  simulation:  a  Group  AN/TSQ-73  with  label  Ql, 
and  an  IHAWK  with  label  Q1W1. 

The  labels  of  the  operators  in  the  system  module 
types  are  printed. 

Select  main  category  of  Air  Defense  unit. 

The  above  selection  results  in  this  secondary 
category  menu. 

Select  Task  Node  Statistics. 

Here  we  select  the  system  modules.  Since  W  is 
specified,  the  Task  Node  Statistics  for  all  IHAWK 
system  modules  will  be  printed.  If  only  one  system 
module  is  desired,  give  its  unique  label. 

There  is  one  statistics  node  in  this  IHAWK  network. 
It  was  activated  1^2  times. 

Request  the  histogram.  The  histogram  is  printed 
showing  how  the  1^2  observations  are  distributed. 
Histogram  parameters  are  specified  on  SAINT  net¬ 
work  data  cards. 

Select  resource  statistics.  Since  these  statistics 
are  summary  statistics  and  we  selected  run  1  ear¬ 
lier  ((§)),  this  is  an  inconsistent  request.  MOPADS 
prints  a  message  to  this  effect. 
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Return  to  the  main  category  menu  and  select  Operators. 

The  secondary  category  menu  contains  only  Task 
Fraction  Statistics.  Select  all  operators  from 
all  IHAWK's. 


Task  Fraction  Statistics  are  printed. 

Select  SAINT  User  Statistics  from  the  main  menu. 

Select  Air  Defense  Unit  and.  specify  the  AH/TSQ-T3. 
Note  that  CONTROL  can  be  specified  for  the  air 
defense  unit  label.  The  effect  Is  the  seme  as  if 
CONTROL  SYSTTM  were  selected  from  this  menu.  CONTROL 
can  be  specified  any  time  the  user  is  asked  for  an 
air  defense  system  label. 

All  three  types  of  user  statistics  are  printed. 
Histograms  are  not  printed,  however,  unless 
specifically  requested. 

Select  Control  System  from  the  main  menu  and 
Cotint  Statistics  from  the  secondary  menu. 

Count  statistics  are  printed  for  the  Control  System 
Module. 


Toggle  the  display  device  so  output  is  printed  at 
both  the  terminal  and  on  the  MGPADS  line  printer 
file.  The  main  category  menu  shows  the  current 
display  option. 


Select  summary  statistics  with  the  USE  command. 
Confirm  with  SHOW.  ,i 

Re-enter  PRINT  and  select  resource  statistics!. 

Select  IHAWK  system  module  from  the  secondaryj  menu. 

Resource  statistics  are  printed. 

Select  Task  Node  statistics  from  the  main  menu  and 
Q1W1  from  the  secondary  menu. 


The  summary  statistics  for  the  one  statistics  node 
are  printed.  Note  that  this  is  the  same  node  seen 
in  Q3)  .  The  average  from  the  lh2  observations  at 
was  0.9921.  This  value  is  recorded  as  an  obser¬ 
vation  of  summary  statistics.  Since  only  one  run 
was  performed,  the  summary  statistics  have  only  this 
one  observation. 
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The  PRINT  command  can  be  exited  from  any  menu 


6-0  CHANGING  THE  STATISTICS 

Statistics  may  be  added/deleted/or  changed  vitfc  relatively 
littl<  difficulty.  In  fact,  some  statistics  can  be  modified  direc¬ 
tly  by  a  MOPADS  user  without  help  from  a  MOPADS  modeler. 

6-1.  Task  Node  Statistics  are  the  easiest  to  change.  These 
statistics  are  specified  by  entries  on  the  data  cards  for  the  system 
module  networks.  If  the  MOPADS  user  is  familiar  with  how  these 
data  cards  are  developed,  then  a  quick  reference  to  the  task  net¬ 
works  in  Goodin  t  Walker  (1983a, b)  will  provide  the  information 
necessary. 

Once  the  desired  statistics  are  specified  on  the  network 
data  cards,  they  are  automatically  collected  by  MSAINT  and  copied 
to  the  User  Interface  at  the  end  of  each  run. 

6-2.  Time  Persistent  Statistics,  Statistics  Based  on 
Observation,  and  User  Histograms  are  easily  specified,  but  they 
require  programming  to  collect  observations.  The  statistics  are 
specified  with  data  cards  as  are  task  node  statistics.  However, 
MSAINT  does  not  automatically  collect  observations.  A  MOPADS 
modeler  must  insert  subroutine  calls  to  the  appropriate  statistics 
programs  in  order  to  record  observations,  see  Walker  (1983) 

6-3-  Count  Statistics  have  no  data  cards.  They  are  specified 
by  including  their  labels  in  a  FORTRAN  DATA  statement  in  BLOCK  DATA 
program  BLOCKY.  Observations  are  recorded  by  calling  SUBROUTINE 
CSTATY  at  the  appropriate  times.  See  Goodin  &  Polito  (1983d)  for 
descriptions  of  the  subprograms. 

6-U.  Operator  Tack  F-action  Statistics  are  collected  auto¬ 
matically  by  MOPADS.  Additions  to  these  statistics  would  occur 
only  if  new  operator  tasks  were  added  to  the  models.  This  would 
be  a  substantial  revision  of  the  modules.  Task  Fraction  Statistics 
for  the  new  tasks  will  be  collected  automatically  if  the  conven¬ 
tions  in  Goodin  &  Walker  (1983a, b)  are  followed. 

6-5-  Resource  Statistics  are  collected  automatically  for  all 
SAINT  resources  that  are  defined.  Resources  with  blank  labels  are 
not  reported,  however.  These  resources  are  specified  on  network 
data  cards. 
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The  PRINT  command  can  be  exited  from  any  menu. 


6-0  CHANGING  THE  STATISTICS 

Statistics  may  be  added/deleted/or  changed  with  relatively 
little  difficulty.  In  fact,  some  statistics  can  be  modified  direc¬ 
tly  by  a  MOPADS  user  without  help  from  a  MOPADS  modeler. 

6-1.  Task  Node  Statistics  are  the  easiest  to  change.  These 
statistics  are  specified  by  entries  on  the  data  cards  for  the  system 
module  networks.  If  the  MOPADS  user  is  familiar  with  how  these 
data  cards  are  developed,  then  a  quick  reference  to  the  task  net¬ 
works  In  Goodin  &  Walker  ( 1983a, b)  will  provide  the  information 
necessary. 

Once  the  desired  statistics  are  specified  on  the  network 
data  cards,  they  are  automatically  collected  by  MSAINT  and  copied 
to  the  User  Interface  at  the  end  of  each  run. 

6-2.  Time  Persistent  Statistics.  Statistics  Based  on 
Observation,  and  User  Histograms  are  easily  specified,  but  they 
require  programming  to  collect  observations.  The  statistics  are 
specified  with  data  cards  as  are  task  node  statistics.  However, 
MSAINT  does  not  automatically  collect  observations.  A  MOPADS 
modeler'  must  insert  subroutine  calls  to  the  appropriate  statistics 
programs  in  order  to  record  observations,  see  Walker  (1983) 

6-3.  Count  Statistics  have  no  data  cards.  They  are  specified 
by  including  their  labels  in  a  FORTRAN  DATA  statement  in  BLOCK  DATA 
program  BLOCKY.  Observations  are  recorded  by  calling  SUBROUTINE 
CSTATY  at  the  appropriate .times.  See  Goodin  t  Polito  (1983d)  for 
descriptions  of  the  subprograms. 

6-b.  Operator  Task  Fraction  Statistics  are  collected  auto¬ 
matically  by  MOPADS.  Additions  to  these  statistics  would  occur 
only  if  new  operator  tasks  were  added  to  the  models.  This  would 
be  a  substantial  revision  of  the  modules.  Task  Fraction  Statistics 
for  the  new  tasks  will  be  collected  automatically  if  the  conven¬ 
tions  in  Goodin  &  Walker  (1983a, b)  are  followed. 

6-5-  Resource  Statistics  are  collected  automatically  for  all 
SAINT  resources  that  are  defined.  Resources  with  blank  labels  are 
not  reported,  however.  These  resources  are  specified  on  network 
data  cards. 
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MOPADS  Terminology 


AIR  DEFENSE  SYSTEM 

A  component  of  Air  Defense  which  includes 
equipment  and  operators  and  for  which 
technical  and  tactical  training  arerequired. 
Example a  are  HLAVK  and  the  AN/TSQ-73. 

AIR  DEFENSE  SYSTEM 
MODULE 

Models  of  operator  actions  and  equipment 
characteristics  fee  Air  Defense  Systems  in 
the  MOPADS  software.  These  models  are  pre¬ 
pared  with  the  SAINT  simulation  language. 

Air  Defense  System  Modules  include  the 

SAINT  model  and  all  data  needed  to  com¬ 
pletely  define  task  element  times,  task 
sequencing  requirements,  and  human  factors 
influences. 

AIR  SCENARIO 

A  spatial  and  temporal  record  of  aerial 
activities  and  characteristics  of  an  air 
defense  battle.  The  Air  Scenario  includes 
aircraft  tracks,  safe  corridors,  ECM,  and 
other  aircraft  and  airspace  data.  See 
also  Tactical  Scenario. 

BRANCHING 

A  term  used  in  the  SAINT  simulation  lang¬ 
uage  to  mean  the  process  by  which  TASK  nodes 
are  sequenced.  At  the  completion  of  the 
simulated  activity  at  a  TASK  node,  the 
Branching  from  that  node  determines  which 
TASK  nodes  will  he  simulated  next. 

DATA  BASE  CONTROL 
SYSTEM 

That  part  of  the  MOPADS  software  which 
performs  all  direct  communication  with  the 
MOPADS  Data  Base.  All  information  transfer 
to  and  from  the  data  base  is  performed  by 
invoking  the  subprograms  which  make  up  the 
Data  Base  Control  System. 

DATA  SOURCE 
SPECIALIST 


A  specialist  in  obtaining  and  interpreting 
Army  documentation  and  other  data  needed  to 
prepare  Air  Defense  System  Modules. 


ENVIRONMENTAL 

STATE  VARIABLE 

An  element  of  an  Environmental  State 

Vector. 

ENVIRONMENTAL 

STATE  VECTOR 

An  array  of  values  representing  conditionr 
or  characteristics  that  may  affect  rcre 
than  one  operator.  Elements  of  £nvirori.en- 
tal  State  Vectors  cay  change  dynamically 
during  a  MOPADS  simulation  tc  represent 
changes  In  the  environment  conditions. 

MODERATOR  FUNCTION 

A  mathematical/logical  relationship  which 
alters  the  nominal  time  to  perform  an  opera¬ 
tor  activity  (usually  a  Tank  Element).  The 
nominal  time  is  changed  to  represent  the 
operator's  capability  tc  perform  the 
activity  based  on  the  Operator's  State 
Vector. 

MOPADS  DATA  BASE 

A  computerized  data  base  designed  specifi¬ 
cally  to  support  the  MOPADS  software.  The 
MOPADS  Data  Base  contains  Simulation  Data 
Set(s).  It  communicates  interactively  with 
MOPADS  Users  during  pre-  and  post-run  data 
specification  and  dynamically  with  the  SAINT 
software  during  simulation. 

MOPAOS  MODELER 

An  analyst  who  will  develop  Air  Defense 
System  Modules  and  modify/develop  the 

MOPADS  software  system. 

MOPADS  USER 

An  analyst  who  will  design  and  c  cm  duct  simu¬ 
lation  experiments  with  the  MOPADS  software. 

MSAINT 

(MQPADS/SAINT) 

The  variant  of  SAINT  used  in  the  MOPADS 
system.  The  standard  version  of  SAHT  has 
been  modified  for  MOPADS  to  pexmit  share¬ 
able  subnetworks  and  more  sophisticated 
interrupts.  The  terms  SAINT  and  MSAINT  ere 
used  interchangeably  when  no  confusion  will 
result.  See  also,  SAINT. 

OPERATOR  STATE 
VARIABLE 

One  element  of  an  Operator  State  Vector. 

OPERATOR  S'*  F  f E 

VECTOR 

An  array  of  values  representing  the  condi¬ 
tion  ana  characteristics  of  an  operator  of 
an  Air  Defense  System.  Many  values  of  the 
Operator  ilcate  Vector  will  change  dynaw!  c  illy 
during  the  '•ourse  of  a  MOPAD'J  simulat_cu  to 
represent  changes  in  operator  condition.  . 

OPERATOR  TASK 

An  operator  activity  identified  during 
weapons  system  front-end  analyses. 

SAINT 

The  underlying  computer  simulation  language 
used  to  model  Air  Defense  Systems  in  Air 
Defense  System  Modules.  SAINT  is  an  acronym 
for  Systems  Analysis  of  Integrated  networks 
of  Tasks.  It  is  a  veil  documented  language 
designed  specifically  to  represent  human 
factors  aspects  of  man/machine  systems. 

See  also  MSAINT. 

SIMULATION  DATA  SET 

The  Tactical  Scenario  plus  all  required 
simulation  initialization  and  other  experi¬ 
mental  data  needed  to  perform  a  MOPADS 
simulation. 

SIMULATION  STATE 

At  any  instant  in  time  of  a  MOPADS  simula¬ 
tion  the  Simulation  State  is  the  set  of 
values  of  all  variables  in  the  MOPAD.:  soft¬ 
ware  and  the  MOPADS  Data  Base. 

SYSTEM  MODULES 

See  Air  Defense  System  Modules. 

The  Air  Scenario  plus  specification  of 
critical  assets  and  the  air  defense  con¬ 
figuration  (number,  type  and  location  of 
veapons  and  the  command  and  control  system) . 


TACTICAL  SCENARIO 


TACTICAL  SCENARIO 
COMPONENT 

An  element  of  a  Tactical  Scenario,  e.g. , 
if  a  Tactical  Scenario  contains  several 
Q-73's,  each  one  is  a  Tactical  Scenario 
Component . 

TASK 

See  Operator  Task. 

TASK  ELEMENTS 

Individual  operator  actions  which,  when 
grouped  appropriately,  make  up  operator 
tasks.  Task  elements  are  usually  repre¬ 
sented  by  single  SAINT  TASK  nodes  in  Air 
Defense  System  Modules. 

TASK  NODE 

A  modeling  symbol  used  in  the  SAINT  simula¬ 
tion  language.  A  TASK  node  represents  an 
activity;  depending  upon  the  modeling  cir¬ 
cumstances,  a  TASK  node  may  represent  an 
individual  activity  such  as  a  Task  Element, 
or  it  may  represent  an  aggregated  activity 
svch  as  an  entire  Operator  Task. 

TASK  SEQUENCING 
MODERATOR 

FUNCTION 

A  mathematical/logical  relationship  which 
selects  the  next  Operator  Task  which  an 
operator  will  perform.  The  selection  is 
based  upon  operator  goal  seeking  character¬ 
istics. 
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1.  INTRODUCTION 


1-0  THE  WORLD  VIEW 

Every  modeling  system  must  settle  on  a  perspective  or  "world 
view"  upon  which  to  construct  representations  of  the  systems  under 
study.  The  world  view  is  important  because  it  determines  the  model¬ 
ing  methodology  and  the  degree  of  detail  which  will  be  represented. 

As  an  example,  consider  building  models  of  nuclear  fission 
processes.  At  the  atomic  level,  nuclear  fission  consists  of  colli¬ 
sions  of  subatomic  particles  which  split  atomic  nuclei  releasing 
energy  and  spawning  other  particles  which  will  go  on  to  collide  with 
still  other  atoms.  The  rate  of  this  reaction  is  determined  by  the 
density  pf  appropriate  atoms  and  the  presence  of  moderating  materials 
which  absorb  subatomic  particles  without  spawning  new  ones. 

| 

This  process  could  be  modeled  by  representing  individual 
nuclear  and  subnuclear  particles  with  a  knowledge  of  the  statistical 
characterizations  of  appropriate  variables.  The  world  view  represen¬ 
ted  by  such  a  model  would  be  as  just  described. 

An  alternative  world  view  is  to  consider  the  fission  process’ 
in  the  aggregate  as  a  thermal  process  whose  rates  can  be  character¬ 
ized  by  shape,  density,  and  orientation  of  the  components.  The 
mathematical  model  for  this  case  is  usually  represented  with  ordinary 
and/or  partial  differential  equations.  The  implicit  assumption  in 
such  models  is  that  the  individual  events  associated  with  a  single 
subatomic  particle  are  insignificant  to  the  aggregate  thermal 
performance. 

There  is  no  "correct"  world  view  for  a  particular  system.  The 
world  view  must  be  chosen  with  an  eye  to  the  objectives  of  the  model. 
In  the  case  of  MOPADS,  the  problem  of  choosing  a  world  view  is  multi¬ 
faceted  because  of  the  many  aspects  of  the  systems  being  represented. 
The  focus  of  MOPADS  is  clearly  an  operator  performance,  but  the 
operators  are  embedded  in  a  system  involving  conmuni cation  (command 
and  control)  and  exogenous  activities  (the  air  battle).  The  way  and 
degree  to  which  each  of  these  aspects  of  the  overall  system  is  repre¬ 
sented  are  discussed  in  Section  II. 

2-0  SOFTWARE  ARCHITECTURE 

I 

A  feecond  purpose  of  this  document  is  to  explain  the  architec¬ 
ture  of  the  MOPADS  software.  The  software  structure  is  discussed  in 
considerable  detail  because  of  the  size  and  complexity  of  the  soft¬ 
ware  system.  Anyone  modifying  the  software  will  need  such  a  detailed 
road  map  in  order  to  confidently  proceed. 


M0PAD3  is  functionally  hierarchical  in  that  functions  are 
separated  in  i  tree  structure  from  the  main  program.  Also,  in 
many  cases,  the  subprogram  calling  sequences  and  structure  have 
been  standardiz  ?a  so  that  nev  eir  defense  system  modules  can  be 
implemented  by  emulating  (wutatis  mutandis'?  one  of  dhe  existing 
system  modules.  Section  III  describes  the  M0PAD3  software  structure 
in  detail. 


II.  THE  MOPADS  WORLD  VIEW 


I- 0  OPERATORS 

The  most  fundamental  assumption  of  MOPADS  is  that  operators 
have  a  finite  capability  to  perform  their  duties.  The  vorkload, 
their  individual  characteristics,  and  the  external  environment  rll 
affect  their  ability  to  perform  their  duties.  Capturing  the  effects 
of  these  variables  on  operators'  performance  i3  the  essential  goal 
of  MOPADS. 

In  response  to  the  external  stimuli  provided  by  the  air  battle, 
operators  perform  the  tasks  (sometimes  called  "critical  tasks*)  pre¬ 
scribed  in  the  system  manuals  for  their  equipment.  Each  cf  these 
tasks  is  usually  composed  of  several  actions  called  "task  elements" 
in  the  MOPADS  terminology.  Task  elements  are  elemental  in  the  MOPADS 
context  because  they  represent  the  lowest  level  of  operator  activity 
that  is  modeled.  Figure  II-l  is  an  example  of  an  operator  task  for 
xhe  AN/TSQ-73  (U.  S.  Army  Technical  Manual,  TM9-1U30-652-10-3) . 

Tasks  consist  of  individual  actions  (shown  in  trapezoids,  e.g. , 

,  simple  decisions  (shown  in  diamonds,  e.g.,(g)),  and  perhaps 
more  complex  activities  that  are  themselves  complete  tasks,  e.g., (3). 
Task  elements  are  the  individual  actions  (i.e.,  trapezoids  in  Figure 

II- l).  It  is,  of  course,  possible  to  consider  the  task  element  as 
complex  physiological  activities.  For  example,  the  activity  labeled 
(l)  in  Figure  II-l  Is  to  press  a  particular  button  on  a  console.  This 
activity  requires  memory  accessess  to  recall  the  general  location  of 
the  button,  muscular  activity  in  the  head  and  eyes  to  visually 
acquire  the  correct  button,  and  muscle  activity  in  the  arm  and  hand 
to  physically  press  the  button. 

MOPADS  does  not  represent  human  activity  to  this  level  of 
detail  because  the  literature  on  human  fattors  does  not  provide  such 
performance  data  as  a  function  of  parameters  which  are  easily 
measured  in  the  air  defense  setting.  The  approach  taken  with  MOPADS 
has  been  to  develop  a  taxonomy  of  skills  which  adequately  represent 
the  activities  of  air  defense  operators  (Laughery  (I98la,b).  The  task 
elements  are  then  described  as  functions  of  the  required  skills. 
Sufficient  data  is  available  to  describe  how  performance  of  the 
various  skills  Is  effected  by  parameters  measurable  in  the  air 
defense  setting. 

This  approach  has  several  advantages  all  of  which  stem  from 
the  following:  the  lowest  level  of  modeling  detail  is  also  -'.he 
lowest  level  of  operator  description  in  official  system  documenta¬ 
tion.  As  a  result,  communication  between  MOPADS  modelers  and 
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Figure  II-l.  Example  Task  for  AN/TSQ-73. 
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subject  matter  experts  is  facilitated.  Data  collection  of  nominal 
task  element  times  is  reduced  to  collecting  information  that  can  be 
obtained  directly  by  observing  operators,  and  the  lowest  level  of 
MOPADS  output  also  corresponds  to  observable  operator  actions. 

Before  performing  a  task,  the  operator  must  select  the  task 
from  among  those  that  are  available.  In  MOPADS  terminology,  this 
is  the  "tusk  sequencing"  activity.  When  the  operator  performs  a 
task,  he  is  essentially  following  a  rule-based  procedure  because 
the  activities  that  comprise  the  task  are  specified  in  official 
system  documentation.  The  tasks  are  step  by  step  procedures  which 
the  operators  memorize.  The  selection  of  which  task  to  perform, 
however,  is  knowledge-based  behavior  in  which  the  operator  calls 
upon  his  experience  to  select  the  task  which  will  most  directly 
lead  to  mission  accomplishment.  In  most  cases,  some  of  the  general 
knowledge  base  has  been  reduced  to  procedures  in  the  form  of 
Tactical  Standard  Operating  Procedures. 

Task  sequencing  is  accomplished  in  MOPADS  by  representing  the 
operators  as  goal  seekers.  Each  operator  has  a  set  of  goals  whose 
levels  of dissatisfaction  can  be  evaluated  and  normalized  to  a  fixed 
scale.  The  values  of  the  goals  on  this  fixed  scale  are  used  to  rank 
the  various  goals  according  to  their  importance.  The  next  task  is 
selected  based  on  estimates  of  how  each  available  task  will  affee* 
the  goal  dissatisfaction  levels. 

Various  objective  functions  are  avilable  in  MOPADS  for  the 
goal  seekers.  The  simplest  is  a  mini-max  strategy  In  which  the 
operator  strives  to  achieve  the  greatest  reduction  in  the  most  dis- 
satisfied  goal  (i.e.,  "put  out  the  biggest  fire  first").  The  most 
complex  is  the  case  in  which  the  operatcr  attemps  to  obtain  the 
largest  reduction  per  unit  time  of  the  average  of  all  goal  dissatis- 
f_ction  levels.  Set  Polito  (1983a)  for  more  information. 

2-0  AIR  DEFENSE  SYSTEMS 

Air  defense  systems  are  components  of  air  defense  which  include 
operators  and  equipment.  Examples  are  the  AN/TSQ-73  and  the  IHAWK. 
The  operators  of  air  defense  systems  are  the  foci  of  MOPADS  models. 

In  general,  the  operator  tasks  which  are  modeled  as  described  in 
Section  1-0  above  are  taken  from  official  documentation  describing 
the  air  defense  system.  The  models  of  the  operator  actions  comprise 
most  of  the  MOPADS  representation  of  the  air  defense  system,  but 
there  are  aspects  of  the  air  defense  system  that  are  not  directly 
related  to  the  operator  models.  For  example,  there  are  crew  actions 
associated  with  set-up,  take-down,  transportation,  and  maintenance 
that  are  not  represented  in  MOPADS.  MOPADS  Is  concerned  with  opera¬ 
tor  performance  in  combat  during  an  air  battle,  and  only  those  opera¬ 
tor  tanks  that  are  pertinent  to  this  objective  are  modeled. 

In  addition,  there  are  non-operator  details  of  the  air  defense 
system  that  must  be  represented  iu  order  to  construct  a  coherent 
model.  These  are  discussed  below. 
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2-1.  The  Environment 


Certain  environmental  variables  affect  human  performance 
such  as  temperature,  noise  level,  illumination,  vibration,  etc.  Also, 
various  system  status  parameters  such  as  veapon?  control  status  and 
method  of  control  may  affect  operator  actions.  These  parameters  are 
stored  in  an  "environmental  state  vector"  far  each  component  of  the 
air  defense  configuration.  These  environmental  ■variables  affect  all 
of  the  operators  serving  in  a  particular  air  defense  component. 

2-2.  Field  of  View.  / 

Knowledge  of  the  air  battle  is  obtained  by  the  air 
defense  configuration  through  radars  and  visual  observations.  Each 
component  of  an  air  defense  configuration  may  have  "viewers"  which 
acquire  information  about  the  air  battle.  In  most  cases,  these  are 
radars,  hut  in  the  case  of  systems  such  as  Redeye,  the  view  is  the 
vis  vial  field  of  the  operator. 

Only  aircraft  that  are  in  the  field  of  view  of  an  air  defense 
component  are  known  to  the  air  defense  configuration.  If  the  ATDL 
is  functioning,  information  on  known  aircraft  is  shared  among  com¬ 
ponents,  however. 

Zero  or  more  viewers  may  be  defined  for  each  component.  The 
field  of  view  of  each  viewer  can  be  defined  in  a  reascmably  flexible 
way  that  permits  such  things  as  ground  obstructions  nnd  restricted 
sweep  angles  to  be  represented.  A  status  for  each  viewer  is  main¬ 
tained,  so  viewers  may  be  modeled  as  becoming  inoperative  during  the 
course  of  a  si munition. 

2-3.  Display  Information. 

Each  air  defense  system  will  present  different  informa¬ 
tion  to  the  opere.tora  which  they  must  process  end  which  will,  in 
part,  determine  their  performance.  The  MOPADS  software  provides 
mechanisms  for  maintaining  operator  display  information.  The  MOPADS 
modeler  must  determine  which  subset  of  the  information  available  to 
the  operator  is  to  be  represented  and  select  the  appropriate  defini¬ 
tions  for  MOPADS  display  parameters.  In  other  words,  the  MOPADS  data 
base  software  provides  mechanisms  to  store  and  retrieve  "display"  infor¬ 
mation,  but  it  does  not  "know"  the  definitions  of  the  individual 
display  variables.  These  definitions  are  determined  by  the  MOPADS 
modeler  when  the  air  defense  system  module  is  developed  and  are  mani¬ 
fested  in  the  simulation  through  the  SAINT  user  code  written  to 
implement  the  system  module. 

2-V.  Hardware  Rcsoures. 

The  air  defense  system  may  have  various  subcomponents 
which  are  necessary  for  one  or  more  of  the  operators  to  perform  hie 
tasks  and  which  are  subject  to  failure  or  in  other  ways  become 


0-14 


unavailable.  Such  subcomponents  represent  "hardware  resources" 
that  the  operators  require  in  order  to  perform  their  functions.  The 
M0R4DS  software  contains  mechanisms  to  define  and  maintain  informa¬ 
tion  about  such  resources.  Hardware  resources  are  similar  to  dis¬ 
play  information  in  that  MOPADS  simply  provides  a  means  to  define, 
store,  and  access  such  information.  The  MOPADS  modeler  mu3t  imple¬ 
ment  the  impact  of  such  resources  on  the  system  when  he  developes 
an  air  defense  system  module.  In  other  vords,  he  smst:  l)  model 
the  mechanisms  by  vh'cb  the  resources  become  available  and  unavail¬ 
able,  2)  model  tue  contingent  procedures  the  operators  will  use  if 
a  required  resource  is  unavailable,  and  3)  maintain  any  desired 
statistical  information  resulting  from  the  hardware  resources. 

3-0  COMMAND,  CONTROL,  AND  COMMUNICATIONS  (C3) 

An  important  aspect  of  an  air  defense  configuration  it  the 
coordination  that  takes  place  between  air  defense  components.  In¬ 
dividual  units  do  not  normally  work  in  isolation.  The  function 
must  be  represented  in  MOPADS  in  order  to  obtain  a  reasonable  repre¬ 
sentation  of  an  air  defense  configuration.  is  not,  however,  the 
primary  focus  of  MOPADS,  and  no  attempt  has  been  made  to  develop  a 
complex,  high  fidelity  model. 

In  practice,  the  C3  functions  are  implemented  by  ccranunl cations 
sent  from  one  air  defense  component  to  one  oi  more  other  components . 
This  process  has  been  mirroz-ed  in  the  MOPADS  software.  The  only 
interaction  between  system  modules  in  a  MOPADS  simulation  la  through 
"messages"  sent  from  one  to  another.  All  C^  function*  are  represen¬ 
ted  as  messages. 

The  type,  content,  and  format  of  messages  may  be  determined  by 
the  MOPADS  modeler  when  a  system  module  la  developed.  Thus,  messages 
that  represent  commands,  status  updates,  acknowledgements,  etc.  can 
be  created  and  transmitted  with  the  MOPADS  message  handling  system. 
This  system  has  several  advantages:  1)  the  representation  in 
MOPADS  can  be  enhanced  at  a  later  date  by  adding  and  modifying  soft¬ 
ware  modules  without  major  structural  changes  to  the  existing  soft¬ 
ware,  2)  the  specific  ccnmsnd  and  control  conflguatioa  can  be 
specified  by  the  MOPADS  modeler  at  run  time,  thus  allowing  different 
conflguations  to  be  simulated  without  re-programming ,  and  3)  new  air 
defense  system  modules  can  be  developed  and  added  to  the  MOPADS  system 
with  very  little  modification  of  existing  system  modules. 

The  main  restriction  on  (3)  above  is  that  if  the  new  system 
module  sends  or  expects  to  receive  a  n->v  message  type,  the  already 
existing  system  modules  must  be  modified  to  send/receive  and  pro¬ 
cess  those  messages. 

To  namarlte,  MOPADS  assumes  that  the  C-*  function  is  embedded 
in  the  operator  tasks,  and  that,  when  required,  operu‘  ,'rs  will 
generate  messages  to  be  transmitted  to  other  system  ca-.r-cnents. 

The  system  modules  must  be  developed  in  such  a  way  that  the  opera¬ 
tors  respond  properly  to  messages  which  they  receive. 
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Finally,  certain  procedural  aspects  of  for  eir  defense 
systems  are  classified.  Since  MOPADS  is  an  urclaasifj  cd  modeling 
system,  generic  or  simplified  representations  of  functions  have 
been  built  into  the  M0PAD6  rjodels.  As  stated  above,  the  models 
could  be  modified  without  undue  effort  to  include  a  more  rich 
representation,  but  the  current  models  are  consistent  vith  a  focus 
on  operator  performance. 

k-0  TACTICAL  SCENARIOS 

Tactical  scenarios  consist  of  an  air  scenario  and  the  physical 
configuration  of  air  defense  components.  In  addition,  protected 
sites  or  "critical  assets"  stay  be  specified  which  the  air  defense 
configuration  will  protect. 

The  MOPADS  modeler  develops  scenarios  by  selecting  a  reference 
position  (latitude,  longitude,  and  altitude).  All  other  locations 
are  specified  by  a  rectangular  coordinate  system  centered  at  the 
reference  point,  X  and  T  coordinates  are  in  units  of  nautica\  miles. 
The  positive  x  direction  is  east  and  positive  y  values  are  north. 

The  Z  coordinate  is  in  feet.  Positive  t  values  are  19. 

Protected  sites  are  specified  by  position,  label,  and  site 
type.  The  site  type  is  defined  by  the  MOPADS  modeler.  The  MOPADS 
software  currently  makes  no  use  of  the  site  types.  The  protected 
sites  are  not  active  participants  in  the  simulation.  In  other 
words,  there  is  no  model  of  activities  at  these  locations.  The 
simulated  air  defense  system  will  simply  attempt  to  attack  hostile 
aircraft  that  approach  these  locations. 


The  location  of  tactical  scenario  components  must  also  be 
specified  by  the  MOPADS  user.  The  air  defense  configuration  will 
automatically  attempt  to  protect  its  own  components.  Thus  the  air 
defense  configuration  will  attempt  to  protect  itself  and  any  other 
sites  designated  as  critical  assets.  Hostile  aircraft  will  be  attacked 
even  if  they  are  not  near  a  protected  site;  however,  priority 
is  given  t<j>  attacking  hostile  aircraft  that  are  approaching  a  pro¬ 
tected  site. 


Hew  ncenarios  are  created  by  specifying  the  flight  paths  of 
aircraft.  Aircraft  may  be  hostile,  friendly,  or  "other."  These 
categories  are  their  true  category  (i.e.,  thier  primary  ID's).  The 
air  defense  configuration  will  recognize  an  aircraft's  category  only 
after  performing  normal  IFF  procedures. 


MOPADS  assumes  a  flat  earth,  and  aircraft  flight  paths  or 
tracks  are  specified  as  piecewise  linear  segments.  In  other  words, 
aircraft  fly  from  point  to  point  (celled  checkpoints)  »  and  between 
checkpoints,  the  aircraft's  direction  and  speed  do  not  change. 

This  is  not  particularly  restrictive  because  as  many  checkpoints  as 
needed  may  be  specified  in  order  to  approximate  curvilinear  motions. 
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Tracks  are  specified  by  their  initiation  tine  (from  the  start 
or  the  simulation),  primary  ID,  multiplicity,  aircraft  type,  and 
initiation  point.  Each  checkpoint  is  characterized  by  the  coordi¬ 
nates  of  the  checkpoint,  speed,  whether  or  not  the  end  point  of  the 
segment  is  a  target,  and  vhether  or  not  the  aircraft  is  jamming  on 
the  segment.  Currently,  MO  PADS  does  not  use  j  waning  information. 

See  Polito  (1983b, c,d)  for  more  detailed  information  on  how 
to  specify  the  information  described  in  this  section. 


III.  SOFTWARE  ARCHITECTURE 


1- 0  OVERVIEW 

The  MOPADS  software  has  been  designed  and  developed  in  a 
modular  fashion.  This  means  that  subprograms  that  have  similar 
functions  are  grouped  together.  They  nay  share  an  internal  data 
structure  and  work  together  to  perform  various  functions.  Programs 
outside  the  module  generally  have  no  knowledge  of  the  data  structures 
or  internal  workings  of  the  module.  External  programs  make  use  of 
the  module  by  subprogram  calls,  and  they  communicate  with  the  module 
only  through  formal  cub program  parameters. 

MOPADS  is  also  functionally  modular  in  that  the  flow  of  control 
of  the  program  is  hierarchical.  This  structure  will  facilitate 
developing  an  overlay  design  for  MOPADS  if  necessary.  MOPADS  has 
been  developed  on  a  virtual  memory  operating  system  and  no  attempt 
has  been  made  to  develop  an  overlay  design  to  fit  iuto  a  specific 
memory  size.  The  design  of  the  software,  however,  should  lend  it¬ 
self  readily  to  overlaying  if  needed. 

2- 0  SOFTWARE  MODULES 

Table  III-l  shows  the  major  MOPADS  software  nodules  and  the 
primary  reference  for  each.  These  programs  (with  the  exception  of 
FFIR2,  Polito  (I983e))  have  been  developed  following  MOPADS  standards 
set  up  in  Walker  &  Polito  (19<52).  Accordingly,  each  module  was 
assigned  a  one  character  suffix.  All  subprogram  names  and  all  COMMON 
variables  in  the  module  end  with  the  assigned  suffix.  Also,  the  pro¬ 
grams  in  each  module  are  documented  in  the  specified  MOPADS  volume 
(also  in  accordance  with  Walker  k  Polito  (198 2)).  The  exception  is 
FFIN2  which  is  composed  of  programs  which  predate  MOPADS.  The  pro¬ 
grams  were  not  modified,  so  they  do  not  use  a  uniform  suffix  or 
follow  other  MOPADS  programming  conventions.  The  module  Is  self  con¬ 
taining,  however,  and  the  documentation  is  of  equal  quality  to  the 
other  references. 

Also,  the  SAINT  software  predates  MOPADS,  and  although  modifi¬ 
cations  were  made  to  SAINT  to  produce  a  MOPADS  specific  variant 
(MSAINT),  no  attempt  was  made  to  make  MSAINT  conform  to  the  require¬ 
ments  of  Walker  k  Polito  (1982).  MSAINT  is  documented  in  Walker  (1983 ). 

The  programs  which  implement  the  air  defense  system  modules  are 
contained  in  the  modules  with  suffixes  C,  Q,  and  W  and  are  documented 
in  Goodin  &  Weaker  (J983a,b).  These  documents  contain  technical  etails 
of  the  software.  User  instructions  for  conducting  simulations  with 
these  modules  may  be  found  in  Goodin  &  Polito  (l9o3a,b). 


Table  III-l.  MOPADS  Software  Modules 


MODULE 

SUFFIX 

REFERENCE 

Data  Base  Application  Program 
(DBAP) 

A 

5.18 

Control  System  Module 

C 

5.19 

Data  Base  Control  System  (DBCS) 

D 

5.13 

AN/TSQ-73  System  Module  (Group) 

G 

5.15 

Human  Factors  Moderator  Functions 

H 

5.10 

User  Interface 

I 

5.12 

Main  MOPADS  Module 

M 

5.12 

AN/TSQ-73  System  Module  (Battalion) 

Q 

5.15 

Free-Format  Syntax  Processor  (FFSP) 

S 

5.11 

MOPADS  Utilities  (UTIL) 

U 

5.9 

IHAWK  System  Modu’e 

W 

5.16 

Common  System  Module  Programs 
(Including  SAINT  User  Code) 

Y 

5.19 

Free-Format  Input  (FFIN2) 

• 

5.14 

The  Control  System  module  (suffix  C)  is  a  special  systr* 
module  that  is  present  in  all  MOPADS  simulations.  It  manajes  the 
MS.iIUT  functions  needed  to  simulate  the  flight  paths  of  aircraft. 

It  contains  control  functions  to  schedule  aircraft  checkpoints, 
initiate  tracks ,  terminate  tracks,  and  maintain  the  data  structure 
used  by  the  other  system  modules. 

The  Data  Base  Control  System  (D)  is  the  software  that  main¬ 
tains  the  MOPADS  data  base.  Other  MOPADS  modules  (with  the  excep¬ 
tion  of  the  user  interface)  seldom  call  this  module  directly.  They 
access  the  data  base  through  the  Data  Base  Application  Programs  (A). 
These  programs  contain  utilities  for  frequently  required  operations 
with  the  data  base. 

The  Human  Factors  Moderator  Functions  (H)  contain  all  of  the 
moderator  function  software.  This  is  a  stand-alone  module  that  has 
a  uniform  and  well  defined  input/output  interface.  Laugh ery  A 
Gavron  (1983)  contains  information  needed  to  use  this  module  in 
non-MOPADS  settings. 

The  User  Interface  (I)  is  a  large  module  that  implements  the 
interactive  software  through  which  the  user  constructs  MOPADS  models, 
specifies  simulation  data,  and  examines  simulation  output .  Hie  Main 
MOPADS  module  (M)  is  documented  with  the  user  interface.  The  Main 
module  consists  of  the  main  program  for  MOPADS  and  a  few  associated 
utilities  that  divert  control  to  the  user  interface  function  or  to 
the  MSAIKT  simulation  function.  The  Free  Format  Syntax  Processor  (S) 

Is  an  input  utility  that  uses  FFIH2,  Polito  (l983e),to  provide  all 
command  driven  input  for  the  user  interface. 

The  MOPADS  utilities  (U)  provide  housekeeping  functions  for  all 
other  MOPADS  modules.  Such  functions  as  array  copying,  file  opening/ 
closing,  etc.  are  performed  by  programs  in  this  module. 

Finally,  there  are  some  programs  that  are  common  across  all 
system  modules.  The  suffix  for  these  programs  is  T.  MSADJT  user 
codes  (e.g. ,  subroutines  STATE  and  UTASK)  are  contained  in  this  module 
even  though  they  do  not  end  with  the  "Y"  suffix. 

The  major  structure  of  the  MOPADS  software  in  "houn  in 
Figure  III-l.  The  small  main  module  determines  whether  the  current 
Job  is  a  user  interface  session  or  a  simulation.  Control  is  trans¬ 
ferred  to  the  appropriate  side  of  the  tree  shown  in  Figure  III-l. 

Control  never  transfers  from  cne  side  to  the  other  side  of  the  tree. 

In  other  words,  each  execution  of  MOPADS  must  be  either  an  interactive 
user  interface  Job  ora  simulation  Job  (which  can  be  run  as  a  batch  Job). 
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This  structure  permits  the  MOPADS  software  to  he  overlaid  in 
a  natural  way.  It  also  allows  MOPADS  to  he  linked  as  two  load 
modules,  if  desired.  The  main  module  and  user  interface  could  he 
linked  as  one  load  module,  and  the  main  module  with  the  SAINT  side 
of  the  tree  can  he  linked  as  another  load  module.  This  strategy 
may  he  useful  on  n  on-virtual  memory  computers  with  limited  Tver  lay 
capabilities  and  limited  memory.  It  may  also  he  desirable  if  MOPADS 
is  merged  vith  other  programs  or  the  simulation  and  user  interface 
functions  are  performed  on  different  computers.  The  independence 
of  the  two  sides  of  the  tree  structure  results  from  the  fact  that 
all  communication  between  the  two  is  through  the  MOPADS  data  hase. 

3-0  MOPADS  USER  INTERFACE  SOFTWARE 

The  user  interface  portion  of  MOPADS  is  shcrwn  in  greater  detail 
in  Figure  III-2.  The  labels  shown  in  the  boxes  are  actual  subprogram 
names.  MDPADM  is  the  name  of  the  main  program  in  MOPADS.  For  user 
interface  sessions  it  calls  MAINUI  which  calls  CFROCI. 

The  main  function  of  CPROCI  is  to  determine  which  user  inter¬ 
face  subprocess  is  to  he  entered.  The  entry  points  to  the  subpro¬ 
cesses  have  names  U11I  to  UI5I-  The  structure  below  UI3I  is  typical 
of  1  the  subprocesses  and  is  not  repeated  for  each  case  in  the 
figure. 


Each  of  the  suhprocesses  has  its  own  set  of  commands.  In 
addition,  there  is  a  set  of  basic  data  hase  commands  that  are 
available  in  all  suhprocesses.  When  a  new  command  is  entered  by  the 
user,  KMNDI  is  called  to  determine  if  it  is  a  basic  ccmmand  or  if  it 
is  one  of  the  commands  specific  to  the  subprocess.  If  the  command 
is  a  basic  data  hase  command,  DBCflil  is  called  which  in  turn  calls 
the  appropriate  subprogram  to  process  the  command. 

If  the  new  command  is  not  one  of  the  basic  commands,  control 
is  returned  from  KMNDI  to  UI3I  (for  example)  which  then  calls  the 
appropriate  subprogram  to  process  the  command  for  that  subprocesa. 
Each  subprocess  has  utility  programs  for  performing  functions  unique 
to  the  subprocess’s  requirements.  Furthermore  all  of  the  subpro¬ 
cesses  make  extensive  use  of  the  modules  DBCS,  DBAP,  FFSP,  FFJN2, 
and  UTIL. 

The  structure  of  the  user  interface  subtree  obviously  can  be 
overlaid,  also.  CPROCI  can  be  a  root  of  a  subtree,  since  only  one 
subprocess  is  active  at  a  time.  Furthermore,  within  each  subprocess, 
each  command  is  processed  by  a  separate  subprogram,  so  opportunities 
exist  for  further  overlays  at  even  this  level.  The  function  of  the 
user  interface  subprocess e3  are  described  in  Polito  (1983b, c,d). 
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4-0  MUPADS  SIMULATION  SOFTWARE 


4-1.  Initialization. 


Figure  III-3  shows  the  major  software  structure  for 
initialization  during  MOPADS  simulation  Johs.  Processing  from 
MOPADM  reads  thn  MOPADS  data  cards  and  determines  that  a  simulation 
(not  a  user  interface)  job  is  in  progress.  MOPADM  then  calls 
BATCHM. 


BATCHM  continues  to  interpret  MOPADS  data  cards.  It  then  con¬ 
structs  a  single  SAINT  network  data  file  by  concatenating  the  net¬ 
work  data  files  for  each  system  module  tha*  will  be  present  in  the 
simulation.  When  this  is  done,  BATCHM  call.'  MSAINT.  SUBROUTINE  MAIN 
is  the  entry  point  to  MSAINT.  MAIN  initializes  SAINT  variables  and 
calls  the  main  MSAINT  programs.  MSAINT  reads  the  network  data  files 
and  calls  SUBROUTINE  UINRJT. 


The  function  of  SUBROUTINE  UINFT  is  to  allow  the  modeler  to 
perform  any  required  initialization  of  system  modules  before 
beginning  any  simulations.  UINPUT  calls  five  programs: 


INITY 

performs  initialization  of  MOPADS  data 
structure  that  is  common  to  all  system 
modules . 

INITC 

- 

performs  initialization  of  the  control 
system  module  that  manages  air  scenario 
information. 

INITG 

- 

performs  initialization  for  the  Group 
AN/TSQ-73  system  module. 

INITQ 

- 

performs  initialization  for  the 

Battalion  AN/TSQ-73  system  module. 

INITW 

- 

performs  initialization  for  the  IHAWK 
system  module. 

Initializations 
to  be  done  only 

performed  from  UNIPF  are  one-time  actions  that  need 
once.  MSAINT  also  calls  SUBROUTINE  USTART  to  per- 

form  initialization  that  must  be  performed  prior  to  each  run. 
USTART  also  calls  the  subprograms  listed  above.  Parameters  are 
passed  to  INITY,  INITC,  INITG,  INITQ,  and  INITW  so  they  can  dis. 
tinguish  whether  the  call  is  from  UINFT  or  USTART. 
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U-2.  Task  Node  Processing. 

MSAINT  provides  the  capability  to  execute  user  code 
at  each  TASK  node  in  the  MOPADS  network.  Figure  1I1-U  shows  the 
structure  for  accomplishing  this.  MSAINT  calls  SUBROUTINE  ITT  ASK 
at  five  points  during  TASK  Lode  processing  (Walker,  1983a):  first 
predecessor  arrival  time  {if  different' from  release  time),  release 
time,  task  ctart  time,  tael  completion  time,  and  task  clearing  time. 
UTASK  is  written  by  the  modeler  to  accomplish  any  needed  programming 
activities  at  these  times. 

In  MOPATS,  UTASK  calls  a  program  for  each  system  module:  e.g. , 
UTGRPG  for  the  group  systau  module.  Each  of  these  programs,  in  turn 
calls  a  program  for  each  task  node  in  the  network  module  of  the 
sytem  module.  As  an  example,  when  TASK  node  four  in  the  Group 
AN/TSQ-73  system  module  is  being  performed,  SUBROUTINE  TUG  will  be 
called  from  UTASK  and  UTGRPG.  T4G  contains  code  written  by  the  KOPADS 
modeler  to  perform  activities  required  for  the  processing  of  that 
node.  The  structural  convention  Bhown  in  Figure  III-U  avoids  confound¬ 
ing  of  U3er  code  by  segrating  the  processing  for  each  TASK  node  in  a 
separate  subprogram. 

b-3.  Error  Processing. 

Error  processing  is  performed  at  several  levels  in  the 
MOPADS  software.  Errors  detected  by  the  Data  Base  Control  System 
(DBCS) ,Polito  (l983f ) ,are  processed  internally  by  the  DBCS.  Fatal 
errors  cause  execution  to  terminate  in  the  DBCS.  Non-fatal  DBCG  errors 
cause  return  to  the  calling  program  with  an  error  indication.  If  the 
calling  program  is  in  the  user  interface,  the  error  is  displayed  at 
the  terminal,  and  the  current  command  is  aborted.  If  the  calling  pro¬ 
gram  is  in  the  simulation  software,  the  Job  is  always  terminated  as 
explained  below. 

Errors  detected  in  the  Data  Base  Application  Programs  (DBAP)t 
Polito  ( 1983g) , always  cause  termination  through  the  DBAP  error  pro¬ 
cessing  program,  ERRORA.  The  error  may  be  a  DBCS  error  or  some  other 
logical  error  condition.  ERRORA  prints  the  offending  data  base  entry 
for  which  the  error  condition  occurred. 

Certain  errors  can  he  detected  by  MSAINT  or  the  system  module 
riser  code.  In  this  case,  standard  MSAINT  error  processing  occurs  as 
shown  in  Figure  III-5.  The  entry  point  to  this  processing  is  MSAINT 
SUBROUTINE  SERR.  SERR  is  called  with  a  integer  error  code.  SERR 
performs  st,uidard  MSAINT  error  output  and  then  calls  SUBROUTINE  UERR. 
UERR  is  written  by  the  MOPADS  modeler.  Various  ranges  of  error  code 
values  (shown  in  Figure  III-5)  have  been  reserved  for  the  different 
system  modules.  UERR  calls  the  correct,  error  processing  program 
(e.g.,  Q73EQ  for  the  AN/TSQ-73).  These  error  processing  subroutines 
are  written  by  the  developers  of  th*-  MOPADS  system  modules  to  produce 
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CALL 

Q73EQ 


t 


Error  Code  Range 

3000-4999 

5000-5499 

5500-5749 

5750-5999 

6000-6999 

7000-7999 

8000-8999 


Figure  III-5 


_ Type  of  Error _ 

MSAINT  Error 

Either  Group  or  Battalion  Q-73  Error 
Group  Only  Error 
Battalion  Only  Error 
IHAWK  Error 

Coirmon  System  Module  Programs 
Control  Error 


T  Error  Processing. 
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any  auxiliary  output  necessary  for  the  specific  error  codes.  Rote 
that  SERB  can  be  and  is  called  with  the  system  nodule  specific  error 
codes  from  programs  written  by  the  modeler  to  implement  the  module. 

For  example,  if  an  error  is  detected  in  SUBROUTINE  TUG  (see  Figure 
III-U) ,  SUBROUTINE  SERR  is  called  at  that  point  with  the  appropriate 
code  value. 

All  calls  to  SUBROUTINE  SERR  terminate  execution  bj  performing 
a  deliberate  FORTRAN  error,  i.e.,  taking  the  square  root  of  a  negative 
number.  Ibis  is  done  so  that  a  txaceback  can  be  obtained  to  the 
offending  subprogram  and  line  number.  Note,  however,  that  on  most 
computer  systems  this  troceback  feature  is  an  option  which  must  be 
explicitly  selected  at  compile  and/or  run  time.  No  traceback  infor¬ 
mation  will  be  printed  if  the  option  has  cot  been  selected. 

User  Functions. 

User  functions  (both  the  input  user  function,  US ERIN, 
and  the  exeuciton  user  functions,  USERF)  may  be  renumbered  for  each 
system  module  type.  In  other  vor&r,  both  the  IHAWK  and  AR/TSQ-73 
system  module  may  have  an  execution  user  function  ntmbered  ”1." 

This  is  implemented  with  the  scheme  shown  in  Figure  III-6.  The 
input  and  execution  user  functions  invoke  FUNCTION  subprograms 
specific  to  the  system  module  being  processed.  These  FUNCTIONS  are 
-mum*  in  a  uniform  way,  e.g.  ,  USERFC,  USERFQ,  USERNC,  USERNQ,  etc. 

This  scheme  allows  user  functions  from  a  system  module  to  be  indepen¬ 
dent  of  user  functions  in  other  system  modules. 

U-5.  MSAIHT  SUBROUTINE  MODRF. 

Unlike  the  user  functions  discussed  above,  the  code  values 
used  for  SUBROUTINE  MODRF  are  not  renumbered  for  each  system  module. 
Therefore,  MOPADS  modelers  must  keep  track  of  MODRF  codes  as  they  are 
used  across  all  system  modules.  Currently  ouly  MODRF  code  one  has  been 
used.  Code  one  is  used  to  implement  the  human  factors  moderator 
functions  for  all  system  modules. 

l»-6 .  Task  Sequencing. 

Each  system  module  has  an  operator  task  for  task  sequencing. 
One  of  the  nodes  that  maki  up  this  task,  e.g,  node  191  in  the 
Battalion  AN/TSQ-73  system  module,  has  responsibility  for  selecting 
the  next  operator  task.  From  UTASK,  a  subroutine  is  called  to  accom¬ 
plish  this  (T191Q  in  the  above  example).  T191Q  can  be  vised  as  a  model 
for  developing  task  sequencing  for  any  future  system  modules.  The 
required  structure  is  shown  in  Figure  III-7  for  the  AN/TSQ-73-  The 
IHAWK  is  similar. 
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Control  AN/TSQ-73  IHAWK 

System  Module 


Control  AN/TSQ-73  IHAWK 

System  Module 


Figure  III-6.  Software  Structure  for  the  Input  and  Execution 
User  Functions. 


T191Q 


Figure  III-T.  Task  Sequencing  Software  Structure  for  the  AN/TSQ-73. 
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T191Q  cells  SUBROUTINE  TSEQY  tc  select  the  next  task.  TSEQY 
calls  GEVALY  to  evaluate  the  current  goal  3tr.tes.  GEVALY  calls  pro¬ 
grams  specific  to  the  system  module  (it.  this  case,  GEVALQ)  to  do 
this.  On  return,  TSEQY  calls  GFRTY  to  evaluate  the  current  goal 
priorities  from  the  3oal  states  (i.e.,  the  goal  dissatisfaction 
levels).  TSEQY  then  calls  OEVALY  to  v-Stimate  the  impact  on  the 
goal  states  that  viJl  i  'suit  from  selecting  the  various  operator  tasks 
available.  OEVALY  calls  a  system  module  specific  program  to  do  this 
(in  this  case,  OEVALQ).  TSEQY  returns  the  selected  task  to  T191Q. 

Adding  new  system  modules  will  require  modifying  GEVALY  and 
OEVALY.  Also,  programs  analogous  to  GEVALQ  and  OEVALQ  must  be 
developed. 

4-7.  External  Files. 

MO PADS  uses  a  number  of  external  files.  Figure  III-8  shows 
the  files.  All  file  unit  numbers  are  stored  in  variables  in  MO PADS. 

The  main  array  to  hold  this  information  is  KUNITM.  The  unit  numbers 
shown  are  the  current  values  of  the  corresponding  elements  of  KUNITM. 
These  values  may  be  changed  to  conform  to  requirements  of  a  particular 
installation  by  modifying  only  one  DATA  statement  iu  BLOCK  DATA  pro¬ 
gram  BLOCKM. 

The  column  "Assigned  By"  in  Figure  III-8  Indicates  how  the  file 
is  associated  with  the  unit  number.  If  this  column  has  an  "M"  in  it, 
it  indicates  that  MOPADS  accesses  these  files  with  FORTRAN  77  OPEN 
and  CLOSE  statements.  No  Job  control  language  is  required  on  most 
computer  systems.  Those  labeled  JCL  require  that  the  indicated  files 
must  be  associated  with  the  correct  unit  number  with  Job  control  language 
prior  to  executing  MOPADS.  Details  of  preparing  MOPADS  data  files  and 
pe’-forming  simulations  is  contained  in  Polito  (1983b). 

5-0  MSAMT  TASK  NETWORKS 

Very  little  needs  to  be  discussed  here  concerning  the  construction 
of  MSAINT  task  networks  because  models  of  system  module  imulementation 
can  be  found  in  Goodin  &  Polito  (1983a, b)  and  Goodin  &  Walker  (l98Sa,b) . 
Some  conventions  are  worth  discussing  here,  however.. 

Operator  tasks  are  numbered  by  the  MOPADS  modeler  (e.g.,  1,2,...), 
and  a  network  model  of  each  is  constructed.  By  convention,  each  task 
is  developed  with  a  3ingle  entry  TASK  node  and  a  single  exit  TASK  node. 
This  helps  to  ensure  that  correct  processing  occurs  before  and  after 
each  task.  Also,  the  node  number  of  the  entry  node  is  always  equal  to 
the  task  number.  For  example,  the  entry  node  to  operator  task  8  is 
TASK  node  8. 

Certain  operator  information  attributes  have  been  reserved  for 
uniform  use.  In  other  words,  their  meanings  are  the  same  no  matter 
what  system  module  the  operator  is  from.  These  attribute  definitions 


Unit  Number 
Variable 

Unit 

Number 

Assigned  * 
By 

File  Description 

KUNITM(l) 

1 

H 

MOPADS  Working  Data  Base 

KUNITM(2) 

2 

M 

MOPADS  Reference  Data  Base 

KUNITM(3) 

3 

K 

MSAINT  Network  Input  File 

KUNITM(4) 

4 

N 

MSAINT  Scratch  File 

KUNITM(5) 

5 

JCL 

MOPADS  Batch  Input  File 

KUNITM(6) 

6 

JCL 

MOPADS  Line  Print  Output 

KUNITM(7) 

7 

- 

Not  used 

KUNITM(8) 

8 

M 

MSAINT  Trace  Output  File 

KUNITM(9) 

9 

JCL 

User  Interface  Interactive 
Input 

KUNITM(lO) 

10 

JCL 

User  Interface  Interactive 
Output 

KUNITM(ll) 

11 

M 

System  Module  Network  Files 

KUNITM( 12) 

12 

- 

Not  used 

KUNITM{13) 

13 

- 

Not  used 

KUNITMf 14) 

14 

mm 

Not  used 

KUNITM( 15) 

15 

Not  used 

NOTE: 

M  -  MOPADS  opens  and  closes  these  files 

JCL  -  These  files  must  be  associated  with  the  correct  unit 
number  with  job  control  language. 


Figure  III-8.  External  Files  Used  By  MOPADS. 


are  shown  in  Table  III-2.  Attributes  not  defined  5.n  Table  III-2 
way  be  defined  to  satisfy  the  modeling  needs  of  a  system  module  under 
development.  Definitions  of  these  attributes  for  the  AH/TSQ-73  and 
IHAWK  are  shown  in  Goodin  &  Walker  (l983a,b). 


Table  III-2.  Standardized  Operator  Information  Attribute  Definitions 


Information  Attribute 
Humber 

Definition 

1 

Operation  ID 

2 

Copy  Row  Humber 

3 

Operator  Type 

See  Walker  (19«3>  for 

discussion  of  these  attributes. 

IV.  CONCLUSION 


This  document  has  presented  an  overview  of  the  MOPAES  modeling 
approach  and  details  of  the  software  implementati  in.  It’s  intended 
audience  is  the  MOPADS  modeler  who  will  maintain  or  extend  the  MOPADS 
system.  Details  of  implementation  are  contained  in  other  documents, 
but  this  volume  provides  a  guide  to  entry  points  in  the  documentation 
and  source  code  for  MOPADS. 

If  new  system  modules  are  developed,  existing  documents  can 
serve  as  models  (e.g. ,  Goodin  &  Polito  (1983a);  Goodin  &  Walker 
(1983a))  for  development.  It  is  strongly  recommended  that  the  for¬ 
mat  of  these  reports  be  used  to  document  any  new  system  modules. 
Furthermore,  if  existing  modules  are  modified,  the  documentation 
should  also  be  revised  to  maintain  up-to-date  reference  material. 


.  v *  \r.  via. 
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I.  INTRODUCTION 


The  MOP.1DS  system  software  contains  several  separate  modules 
which  interact  through  software  interfaces.  These  modules  will  he 
developed  independently  by  different  programmers  and  will  be  inte¬ 
grated  to  form  the  MOPADS  system. 

In  order  to  assure  that  this  software  development  effort  goes 
smoothly,  it  is  necessary  that  common  programming  and  documentation 
guidelines  be  followed  by  all  software  developers.  Following  these 
guidelines  will  facilitate  debugging,  modification,  and  maintenance 
of  the  MOPADS  software. 

All  non-operator  MOPADS  software  and  SAINT  user  written 
FORTRAN  (operator  software)  will  conform  to  the  requirements  in 
this  manual .  For  additional  guidance  on  preparing  MOPADS  operator 
modules,  see  reference  1. 

In  Section  II,  the  programming  conventions  to  be  followed  are 
described.  The  conventions  are  broken  down  into  two  groups.  The 
first  group  contains  global  considerations  involving  each  module 
and  its  subprograms .  The  second  group  contains  the  programming  con¬ 
ventions  to  be  followed  when  coding  individual  subprograms.  Included 
in  Section  II  is  a  sample  subprogram  showing  the  standard  layout  to 
be  used. 


Section  III  contains  the  requirements  for  documenting  each 
MOPADS  software  module.  Each  module  will  have  its  own  program 
documentation  manual,  and  the  requirements  for  preparing  these 
manuals  are  specified  in  this  section. 

These  guidelines  should  place  minimum  restrictions  on  the 
coding  style  of  the  software  development  personnel  while  maximizing 
the  ease  with  which  the  coordination  effort  and  future  modifications 
can  be  performed. 
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1-0.  GLOBAL  CONSIDERATIONS 

1-1.  Each  module  will  be  assigned  a  one  character  suffix  by 
the  MOPADS  Software  Coordinator,  lhis  suffix  will  be  attached  to 
the  end  of  all  subprogram  names,  COMMON  variable  names,  and  labeled. 
COMMON  block  names  in  the  module. 

1-2.  The  number  of  separate  labeled  COMMON  blocks  in  a  module 
will  be  minimized  while  the  following  guidelines  are  used: 

1.  No  COMMON  statement  should  have  more  than 
four  continuations . 

2.  Variables  may  be  grouped  by  function  into 
separate  COMMON  blocks. 

3.  "Special  purpose"  COMMON  blocks  with  only  a 
few  variables  to  communicate  between  a  few 
subprograms  are  prohibited. 


1-3.  The  variables  within  each  COMMON  block  must  be  in  alpha¬ 
betical  order. 

1-1*.  No  blank  (unlabeled)  COMMON  usage  is  allowed. 

1-5.  Each  module  will  have  one  error  processing  routine. 

This  routine  will  be  named  ERROR 7.  where  7_  is  the  one  character 
module  specific  suffix. 


1-6.  Each  module  will  have  at  most  one  BLOCK  DATA  program. 
The  BLOCK  DATA  program  will  be  named  BLOCK7_  where  _?  is  the  one 
character  module  specific  suffix . 


1-7.  All  MCPADS  software  will,  be  written  in  ANSI' 

FORTRAN  77 12]  •  nonstandard  features  or  syntax  are  to  be  used, 

and  no  Hollerith  variables  will  be  vised.  (SAINT  will  remain  in  ANSI 
FORTRAN  IV,  but  all  user  code  will  be  written  in  FORTRAN  77.) 

1-8.  All  subprograms  will  be  placed  in  alphabetical  order 
within  each  module. 

1-9.  Modular  programming  design  will  be  used,  and  each  sub¬ 
program  will  have  a  single  purpose.  Very  long  subprograms  should 
be  avoided.  As  a  general  guideline,  no  subprogram  should  be  longer 
than  200  to  300  non-comment  lines. 
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1-10.  All  software  developed  on  the  Pritsker  &  Associates.'  VAX 
11/780  will  use  .the  I  AMP  programs  and  procedures. 


1-11.  All  logical  unit  numbers  for  external  files  to  be 
opened  and  closed  for  use  by  non-operator  software;  will  be  obtained 
from  the  MOPADS  Software  Coordinator. 

1-12.  All  I/O  statements  will  use  a  variable  name  for  the 
logical  unit  number.  These  variables  will  be  placed  in  COMMON. 

1-13 •  Whenever  the  program  size  might  need  to  be  increased, 
array  dimensions  will  be  specified  in  a  FORTRAN  77  PARAMETER  state¬ 
ment.  (On  the  Pritsker  &  Associates's  VAX,  if  the  arrays  are  ijn 
COMMON,  the  PARAMETER  statement  will  be  included  in  the  LAMP  COMDECK.) 

1-lU.  Each  module  will  have  a  single  initialization  subprogram 
named  INIT?_,  where  _?  is  the  one  character  module-specific  suffix. 


SUBPROGRAM  CODING 


2-1.  Comments  should  be  used  frequently  to  explain  non- 
obvious  statements  or  blocks  of  code.  As  a  general  rule,  no  block 
of  code  should  be  longer  than  about  ten  (10)  lines  without  a  comment. 

. 

2-2.  No  more  than  one  array  will  be  initialized  in  a  single 
data  statement.  For  arrays  of  more  them  one  dimension,  the  data 
statement  should  be  layed  out  in  a  readable  manner. 
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No  variable  name  may  be  split  between  continuation 
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2-4.  FORMAT  statements  will  not  use  all  available  72  columns 
before  continuation.  FORMAT  "fields"  (specifications  separated 
by  commas)  should  not  be  split  between  continuation  lines. 

2-5.  The  list  of  formal  parameters  in  a  SUBROUTINE  or  FUNCTION 
statement  will  be  in  the  following  order: 

1.  Input  only  parametes. 

2.  Input/output  parameters. 

3.  Output  only  parameters. 

4.  Alternate  returns. 

2-6.  Each  external  file  will  be  explicitly  opened  and  closed 
using  the  OPEN  and  CLOSE  statements . 

2-7.  Each  block-if  will  be  indented  by  two  (2)  spaces  as  in 
the  following  two  examples. 
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1.  IF  (I.BQ.5)  THEN 

XXV AL  «  -1.0 
GO  TO  999 
ENDIF 

2.  IF  (NPT.LT.O)  THEN 

NERR  =  500 
ELSE 

NERR  •=  1000 
ENDIF 

2-8.  Each  DO  loop  with  more  than  one  statement  will  have  its 
own  labeled  CONTINUE  statement. 

2-9.  The  TYPE  statements  INTEGER,  REAL,  and  IMPLICIT  will 
not  be  used. 

2-10.  Each  subprogram  will  have  one  and  or'  /  one  return 
statement.  One  of  the  two  options  shown  below  will  be  used: 

1.  - 


999  RETURN 
END 

2.  - 


999  CONTINUE  .  a  ^ 

HjjjUjyj*  '  **“*(0nly  debugging  statements 

are  allowed  here . ) 

2-11.  Statement  numbers  will  be  in  ascending  order,  with  the 
RETURN  (or  preceding  CONTINUE  to  the  RETURN)  labeled  999  and  all 
FORMAT  statements  using  numbers  from  1000  to  1999* 

2-12.  All  variable  length  arrays  passed  to  subprograms  as 
formal  parameters  will  have  adjustable  dimensions  in  the  subpro¬ 
grams  (i.e.,  the  array  bounds  must  be  passed  as  formal  parameters 
or  be  contained  in  a  COMMON  or  PARAMETER  statement  in  the  subprogram) . 
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2-13.  Each  subprogram  will  be  Organized  in  the  following 
Sections  not  needed  will  be  excluded. 


Comment  statement  with  'C:*  in  the  first 
two  columns . 

Subprogram  name  and  arguments . 

Block  of  c eminent  statements  in  the  following 
order : 

a.  MOPADS  module  name 

b.  MOPADS  documentation  reference 

c.  Description  of  the  purpose  of  the  subprogram 

d.  Definitions  of  input  only  parameters 

e.  Definitions  of  input /output  parameters 

f.  Definitions  of  output  only  parameters 

g.  Descriptions  of  till  alternate  returns 

h.  Comment  statement  with  * C : : *  in  the  first 
three  columns 

i.  Definitions  of  local  variables  whose  usage 

is  not  readily  apparent 

AH  DIMENSION  statements  (perhaps  preceded 
by  their  PARAMETER  statements ) . 

All  COMMON  ctatements  (perhaps  preceded  by 
their  PARAMETER  statements). 

All  EQUIVALENCE  statements. 

All  DATA  statements. 

Main  body  of  the  subprogram  with  statement 
numbers  (1-998)  in  ascending  order. 

RETURN  statement  (labeled  999). 

All  FORMAT  statements  (1000-1999). 

END  statement. 
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3-0.  SAMPLE  SUBPROGRAM  SHOWING  STANDARD  LAYOUT  . 

The  following  example  conforms  to  the  previous  requirements. 

Ct  SUBROUTINE  DFXND(XVAL» XARRAY »NDXM?TGL»NCURR» IPX »IERR»X> 

Exxmodule:  mopads/module  name 
cxxreference;  mopads/vqlume  number 

CXXPURPOSES  THIS  SUBROUTINE  RETURNS  THE  ARRAY  INDEX  FOR  THE 
C  FIRST  (OR  NEXT)  ARRAY  ELEMENT  WHICH  IS  EQUAL  TO 

C  A  GIVEN  VALUE  ♦  OR  -  A  SPECIFIED  TOLERANCE. 


XVAL-VALUE  TO  BE  COMPARED 
XARRAY-ARRAY  NAME  FOR  ARRAY  TO  BE 
SEARCHED 

NDIN-UIHENSZDN  OF  X ARRAY 
TOLnTOLERANCE  USED  IN  COMPARING  XVAL 
TO  THE  ELEMENTS  OF  XARRAY 


CXXINPUT  parameters: 

i 

c 
c 

s 

gXX INPUT/OUTPUT  PARS 

8 

CXXOUTPUT  PARAMETERS:  XDX-THE  INDEX  OF  ARRAY  XARRAY  SUCH  THAT 

XVAL  ♦  OR  -  TOL  ■  XARRAY (IDX> 

IERR-0  |f  HgN|RFgUNDAND  JK  ^  ggT 

2  IF  NCURR>NDIM 


C 

8 

i 


NCURR-THE  INDEX  OF  THE  ARRAY  WHERE  THE 

SEARCH  IS  TO  BE  STARTED.  RETURNED 
AS  IDXfl  IF  2ERR-1 


CXXALTERNATE  RETURNS:  THE  SINGLE  ALTERNATE  RETURN  OCCURS  WHEN 

C  I ERR  NOT  EQUAL  1 

ct 

gXXLOCAL  VARIABLES!  Kh 

C  DIMENSION  XARRAY (NDIM) 

C  IDX  -  0 

IRT  ■  0 
IERR  ■  0 
XPLU3  ■  XVAL+TOL 
XMINUS  •  XVAL-TOL 
IF(NCURR.GT.NDIM)  THEN 
IERR  •  2 
IRT  ■  1 
GO  TO  999 
ENDIF 

CXXSEARCH  XARRAY  STARTING  AT  ELEMENT  NCURR 

C  • 

DO  100  1 -NCURR » NDIM 

IF(XARRAT<  I).GE. XMINUS.  AND. XARRAY  ( I  ).LE.XPLUS)THEN 
IDX  ■  X 
NCURR  •  I+I 
IERR  -1 
GO  TO  999 

ioo  EonJinue 

c 

CXXNOT  FOUND 

C  IRT  -  t 

C999  RETURN  IRT 
END 
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III.  DOCUMENTATION  REQUIREMENTS  FOR  MOFADS 
NON-OPERATOR  SOFTWARE  MODULES 

Each  module  will'  have  its  own  program  documentation  manual. 

Each  of  these  manuals  will  have  the  following  table  of  contents. 

A  description  of  each  section  follows. 

1- 0.  TABLE  OF  CONTENTS 

j 

I  Purpose 

II  Data  structures  descriptions 

III  Overview  of  the  fluw-of-control 

IV  External  file  usage 

V  Subprogram  descriptions 

VI  User  Instructions 

VII  Error  processing 

VIII  COMMON  variable  definitions 

I 

2- 0.  DESCRIPTION  OF  EACH  SECTION 

2-1*  Purpose.  This  section  will  serve  to  Introduce  the  reader 
to  the  module.  The  propose  and  scope  of  the  module  will  be  dis¬ 
cussed.  When  the  reader  finishes  the  section,  he/she  should  under¬ 
stand  the  function  of  the  module. 


2-2.  Data  Structures  Descriptions.  Array,  tree,  list,  end 
pointer  usage  should  be  described  here.  These  descriptions  may 
include  tables,  diagrams,  or  pictures.  Modules  which  create 
entries  in  the  MOPADS  data  base  must  define  this  usage  in  this 
section. 

2-3.  Overview  of  the  Flov-of-Control .  This  entails  a 
description  of  how  the  module  fits  into  the  MOPADS  system,  how  the 
module  is  entered  and  exited,  and  some  description  of  the  flcrw-of- 
control  of  the  module.  A  hierarchy  chart  may  be  included  here. 

2— U.  External  File  Usage.  A  short  description  of 
the  v«jage  of  each  external  file  used  oy  this  module  should  be 
included.  The  type  of  file  should  be  given  as  well  as  a  discussion 
of  when  the  file  is  opened  and  closed. 

2-5.  Subprogram  Descriptions.  Every  subprogram  must  be 
described.  The  purpose  and  parameter  definitions  from  the  sub¬ 
program  comment  section  may  be  included  here.  These  subprogram 
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descriptions  will  be  in  alphabetical  order.  In  addition  to  the 
purpose  and  parameter  definitions,  sane  discussion  should  be  im- 
eluded  describing  the  method  and/or  flow-of-control  within  the 
subprogram.  Flowcharts  should  be  included  for  very  long  subprograms. 
Any  local  data  structures  should  be  described.  Alternate  ESTHY'a 
into  a  subprogram  will  be  documented  ms  though  they  were  separate 
subprograms . 

2-€.  User  Instructions.  This  section  should  contain 
descriptions  of  how  to  use  the  module.  Examples  may  be  provided. 
Reference  may  be  made  to  Section  V  for  detailed  program  descriptions 
rather  than  repeating  them  here.  The  instructions  given  in  this 
section  should  be  issue  driven.  In  other  words,  explain  how  to  use 
the  module  to  accomplish  its  purpose. 

2-7.  Error  Processing.  The  error  processing  programs  will 
be  discussed  here.  If  error  codes  are  used,  each  will  be  defined  in 
this  section.  A  discussion  of  the  types  of  errors  that  are  detected 
and  what  action  is  taken  will  be  included. 

2-8.  COWOW  Variable  Definitions.  A  table  of  all  COMMQI 
variables,  their  definitions,  and  their  initial  values  (if 
appropriate)  will  be  included.  The  variables  may  be  either  alpha* 
betized  within  or  across  COMMOff  blocks.  In  any  case,  the  COWOH 
block  name  in  which  a  variable  appears  must  be  clearly  identified. 
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TERMINOLOGY 


1-0  STANDARD  MOPADS  TERMINOLOGY. 


AIR  DEFENSE  SYSTEM  A  component  of  Air  Defense  which  includes 

equipment  and  operators  and  for  which  techni¬ 
cal  and  tactical  training  are  required. 
Examples  are  IHAWK  and  the  AN/TSQ-73. 


AIR  DEFENSE  SYSTEM  Models  of  operator  actions  and  equipment 
MODULE  characteristics  for  Air  Defense  Systems  in 

the  MOPADS  software.  These  models  are  pre¬ 
pared  with  the  SAINT  simulation  language. 

Air  Defense  System  Modules  include  the  SAINT 
model  and  all  data  needed  to  completely 
define  task  element  time,  task  sequencing 
requirements,  and  human  factors  influences. 


AIR  SCENARIO  A  spatial  and  temporal  record  of  aerial 

activities  and  characteristics  of  an  air 
defense  "battle.  The  Air  Scenario  includes 
aircraft  tracks,  safe  corridors,  ECM,  and 
other  aircraft  and  airspace  data.  See  also 
Tactical  Scenario. 


BRANCHING  A  term  used  in  the  SAINT  simulation  language 

to  mean  the  process  by  which  TASK  nodes  are 
sequenced.  At  the  completion  of  the  simulated 
activity  at  a  TASK  node,  the  Branching  from 
that  node  '“termines  which  TASK  nodes  will  be 
simulated  ni.xt. 


DATA  BASE  CONTROL  That  part  of  the  MOPADS  software  which  performs 

SYSTEM  all  direct  communication  with  the  MOPADS  Data 

Base.  All  information  transfer  to  and  from 
the  data  base  is  performed  by  invoking  the  sub¬ 
programs  which  make  up  the  Data  Base  Control 
System. 


DATA  SOURCE  A  specialist  in  obtaining  and  interpreting 

SPECIALIST  Army  documentation  and  other  data  needed  to 

prepare  Air  Defense  System  Modules. 


ENVIRONMENTAL  An  element  of  an  Environmental  State  Vector. 

STATE  VARIABLE 


ENVIRONMENTAL 
STATE  VECTOR 


ENVIRONMENTAL  An  array  of  values  representing  conditions  or 

STATE  VECTOR  characteristics  that  may  affect  more  than  one 

operator.  Elements  of  Environmental  State 
Vectors  may  change  dynamically  during  a  MOPADS 
simulation  to  represent  changes  in  the  environ¬ 
ment  conditions. 

MODERATOR  FUNCTION 

A  mathematical/logical  relationship  which 
alter 3  the  nominal  time  to  perform  an  operator 
activity  (usually  a  Task  Element).  The  nominal 
time  is  changed  to  represent  the  operator's 
capability  to  perform  the  activity  based  on  the 
Operator's  State  Vector. 

MOPADS  DATA  BASE 

A  computerized  data  base  designed  specifically 
to  support  the  MOPADS  software.  The  MOPADS 

Data  Base  contains  Simulation  Data  Set(s).  It 
communicates  interactively  with  MOPADS  Users 
during  pre-  and  post-run  data  specification  and 
dynamically  with  the  SAMT  software  during 
simulation. 

MOPADS  MODELER 

An  analyst  who  will  develop  Air  Defense  System 
Modules  and  modify/develop  the  MOPADS  software 
system. 

MOPADS  USER 

An  analyst  who  will  design  and  conduct  simu¬ 
lation  experiments  with  the  MOPADS  software. 

MSAINT(M0PADS/3AINT) 

The  variant  of  SAIflT  used  in  the  MOPADS  system. 
The  standard  version  of  SAIBT  has  been  modified 
for  MOPADS  to  permit  shareable  subnetworks  and 
more  sophisticated  interrupts.  The  terms  SAIKT 
and  MSAIIJT  are  used  interchangeably  when  no 
confusion  will  result.  See  also,  SAIKT. 

OPERATOR  STATE 
VARIABLE 

One  element  of  an  Operator  State  Vector. 

OPERATOR  STATE 

VECTOR 

* 

An  array  of  values  representing  the  condition 
and  characteristics  of  an  operator  of  an  Air 
Defense  System.  Many  values  'of  the  Operator 
State  Vector  will  change  dynamically  during 
the  course  of  a  MOPADS  simulation  to  represent 
changes  in  operator  condition. 

OPERATOR  TASK  As  operator  activity  identified  during 

weapons  system  frost-end  sarlyses- 


SAINT  The  underlying  c coput er  simulation  language 

used  to  model  Air  Defease  Systems  in  Air 
Defense  System  Modules.  SAINT  is  an  acronym 
far  Systems  Analysis  of  Integrated  letvorks  of 
Tasks.  It  is  a  veil  documented  language  designed 
specifically  to  represent  human  factors  aspects 
of  man/machine  systems.  See  also  KSAUJT. 


SIMULATION  DATA  SET 


SIMULATION  STATE 


The  Tactical  Scenario  plus 
lation  initialization  and 
data  needed  bo  perform  a  MO 


required  sinn¬ 
er  experimental 
simulation. 


At  any  instant  in  time  of  a  MOPADS  simulation 
the  Simulation  State  is  the  aet  of  values  of  all 
variables  in  the  MOPADS  software  and  the  MOPADS 
Data  Base. 


SYSTEM  MODULES  See  Air  Defense  System  Modules. 


TACTICAL  SCENARIO  The  Air  Scenario  plus  specification  of  critical 

assets  and  the  air  defense  configuration 
(number,  type  end  location  of*  weapons  and  the 
command  and  control  system). 


TACTICAL  SCENARIO  An  element  of  a  Tactical  Scenario^  e.g.,  if  a 

COMPONENT  Tactical  Scenario  contains  Several  Q-T3's,  each 

one  is  a  Tactical  Scenario  iqmponent. 


TASK 


See  Operator  Task. 


Individual  operator  actions  which,  when  grouped 
appropriately,  make  up  operator  tasks.  Task 
elements  are  usually  represented  by  single 
SAINT  TASK  nodes  in  Air  Defense  System  Modules. 


TASK  ELEMENTS 


TASK  NODE 


A  modeling  symbol  used  in  the  SAIHT  simu¬ 
lation  language.  A  TASK  node  represents 
an  activity;  depending  upon  the  modeling 
circumstances ,  a  TASK  node  may  represent 
an  individual  activity  such  as  a  Task 
Element ,  or  it  may  represent  an  aggregated 
activity  such  as  an  entire  Operator  Task. 


TASK  SEQUENCING  A  mathematical /logical  relationship  vhicb 

MODERATOR  FUNCTION  selects  the  next  Operator  Taak  which  an 

operator  will  perform.  The  selection  is 
baaed  upon  operator  goal  seeking 
characteristics. 
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INTRODUCTION 


The  MOPADS  software  will  allow  multiple  air  defense  system 
modules  to  be  built  and  "plugged  in"  to  the  overall  system.  These 
SAINT  modules  will  each  represent  operation  of  an  air  defense 
component.  They  will  most  likely  be  developed  independently,  and 
it  can  be  expected  that  many  changes  will  be  made  to  the  models 
during  their  useful  life.  This  requires  that  each  module  be  well 
documented  so  that  other  MOPADS  modelers  (or  the  same  modeler  at 
a  later  time)  can  understand  the  workings  of  each  module.  This 
report  outlines  the  methodology  that  will  be  used  in  documenting 
all  MOPADS  system  modules . 

Each  system  module  will  have  its  own  documentation  and  ref¬ 
erence  manual ,  and  each  of  these  manuals  will  follow  the  sane  basic 
format.  Section  II  contains  the  standard  table  of  contents  for  each 
manual . 


Section  III  contains  descriptions  and  explanations  of  the 
contents  of  each  chapter  listed  in  the  standard  table  of  contents. 

A  major  portion  of  each  of  these  manuals  will  be  a  collection 
of  forms  which  describe  the  entities,  resources,  variables,  etc, 
in  the  model.  Sample  forms  with  example  contents  are  included  In 
Section  III.  3-0. 

Section  IV  snows  the  blank  fores  needed  by  the  J40FADS  modeler. 
Under  separate  cover  full-size  forms  vill  be  sent  to  the  M0PAE6 
modeler.  These  ferns  should  all  be  kept  in  a  notebook  and  filled 
out  as  the  information  in  them  becomes  available  during  system  module 
development.  All  forms  of  a  given  type  should  be  kept  together, 
and  the  forms  should  be  put  in  the  same  order  as  the  forms  appear 
in  Section  IV. 
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II.  STANDARD  MODULE  TABLE  OF  CONTENTS 


Since  each  system  module  documentation  manual  will  contain 
the  same  type  of  information,  the  documentation  task  will  be 
simpler  if  each  ha3  the  same  organization.  A  standard  table  of 
contents  in  shown  in  Figure  II -1. 
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I.  SYSTEM  DESCRIPTION 

II.  OVERVIEW  OF  THE  SAINT  MODEL 


III.  MODEL  DESCRIPTION  FORMS 

1- 0  Entities 

2- 0  Resources 

3- 0  Variables 

l*-0  Monitors 

5- 0  Task  Descriptions 

6- 0  Statistics 

T-0  User  Functions 

8-0  Moderator  Functions 


IV.  USER  WRITTEN  SUBPROGRAMS 

1- 0  Index 

2- 0  Subprogram  Descriptions 

3- 0  Subprogram  Listings 


V.  LISTING  OF  SAINT  NETWORK  DATA  INPUT 


VI.  NON-SAINT  DATA  REQUIREMENTS 

1- 0  Data  Requirements 

2- 0  Data  Source  and  Description 

VII.  OUTPUT  REPORTS 

1- 0  Output  Options 

2- -0  Sample  Output 


Figure  II-l.  Table  of  Contents  for  MOPADS  Syctem  Module 
Documentation 
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III.  DESCRIPTION  OF  THE  DOCUMENTATION  CONTENTS 


In  thi3  section  the  contents  of  the  system  module  docu- 
nentation  manual  are  explained  and  discussed.  Each  heading  in  this 
section  corresponds  to  a  chapter  to  be  included  in  the  manuals. 

1-0  SYSTEM  DESCRIPTION. 

The  system  being  modeled  will  be  described  here.  This  des¬ 
cription  should  include  discussions  of  which  equipment  is  included 
in  the  system ,  what  operators  run  the  equipment ,  and  how  the  equip¬ 
ment  is  operated.  Some  discussion  of  how  this  equipment  interfaces 
with  other  equipment  should  be  included.  This  section  may  include 
diagrams  or  pictures  from  technical  manuals,  soldier’s  manuals,  or 
field  manuals.  Any  special  configurations  of  the  equipment  should 
be  described. 


2-0  OVERVIEW  OF  THE  SAINT  MODEL. 

The  modeling  approach  applied  to  the  system  will  be  explained 
here.  This  explanation  will  include  such  items  as  simplifying 
assumptions,  overall  modeling  framework,  modifier  aspects  of  the 
model,  and  the  flow-of-oontrol  of  the  network  model.  Detailed  dis¬ 
cussions  of  the  model  should  be  reserved  for  the  following  section. 
The  reader  should  be  able  to  get  a  feel  for  the  basic  model  struc¬ 
ture  by  reading  this  section. 


3-0  MODEL  DESCRIPTION  FORMS. 

In  order  to  simplify  the  model  documentation  process,  several 
forms  have  been  developed.  These  forms  are  intended  to  be  kept  in 
a  notebook  and  filled  in  as  the  model  is  being  developed.  In  this 
way,  they  serve  as  working  documentation  during  model  development.  If 
the  MOPADS  modeler  is  diligent  in  maintaining  the  forms,  then  the  final 
documentation  tasks  will  be  much  simpler  and  nothing  of  significance 
to  the  model  will  be  forgotten.  The  use  of  each  form  is  explained, 
and  a  filled  out  samp.le  of  each  form  is  included  in  this  report. 

3-1.  Entities . 

A  sample  Entities  form  is  shown  in  Figure  III-l. 

Entities  are  described  in  reference  [1]  and  they  may  be  operators 
or  information  flows.  An  entity  is  created  in  a  SAINT  network 
either  at  a  source  node  or  at  a  regular  task  node  through  mulitple 
branching.  Regardless  of  which  method  is  used,  the  task  node 


number  where  the  entity  is  created  will  be  entered  in  the  first 
column.  The  entity  will  be  briefly  described  in  the  second  column, 
and  this  description  should  tell  the  reader  what  each  entity 
represents.  Each  entity  has  a  collection  of  attributes,  called 
information  attributes,  which  follow  the  entity  through  the  SAINT 
network.  Each  attribute  number  will  be  listed  in  the  third  column, 
accompanied  by  a  brief  definition  describing  its  meaning  and 
initial  value,  if  appropriate.  Information  attributes  are  inltJ  - 
ized  through  the  ATAS  descriptor  on  the  task  node  where  the  er^  uy 
originates.  It  is  probable  that  each  entity  requires  the  r  r,  of 
at  least  one  resource  to  perform  one  or  more  tasks  in  the  network. 
If  so,  each  resource  which  the  entity  references  throughout  the 
network  should  be  listed  in  the  far  right  column.  These  entries 
should  consist  of  the  resource  number,  followed  by  a  comma,  then 
the  resource  label. 

3-2.  Resources . 

The  SAINT  simulation  methodology  allows  for  the  use  of 
resources  for  modeling  applications.  (See  reference  1  for  further 
discussion  on  the  use  of  resources.)  A  sample  resources  form  is 
shown  in  Figure  III-2. 

Each  resource  number  will  be  listed  in  the  first  column  with 
the  corresponding  resource  label  adjacent  to  it  in  the  second 
column.  Under  the  "Description  of  Use"  column,  the  resource  should 
be  defined  and  some  discussion  should  be  included  describing  how 
each  resource  is  used. 

Each  resource  may  have  resource  attributes.  Each  resource 
attribute  number  will  be  listed,  followed  by  a  brief  definition  of 
the  resource  attribute  and  its  initial  value.  Resource  attributes 
are  initialized  on  IRA  cards.  All  task  numbers  requiring  the 
resource  are  listed  in  the  last  column.  This  information  is 
extremely  valuable  when  network  changes  are  made  involving  the 
resource. 

3-3.  Variables . 

Each  SAINT  model  will  have  many  variables  -chat  are 
global  in  nature.  There  are  three  types  of  global  variables: 

1.  state  variables 

2.  system  attributes 

3.  user  variables. 

All  of  these  will  be  entered  on  the  same  form,  but  they  will  be 
separated  by  type.  Examples  showing  the  use  of  the  variables  form 
are  snown  in  Figures  III-3,  Ill-h,  and  III-5. 


3. 3.  a.  State  variables,  figure  III-3  shows  the  use 
of  the  variables  form  for  documenting  state  variables.  Hear  the 
bottom  of  the  form, the  type  of  variable  is  checked;  in  this  case 
the  state  variables  box  is  checked.  The  variable  name  is  placed  in 
the  first  column  as  SS(*)  or  DD(*)  (where  *  is  the  state  variable 
index  number).  In  the  second  column,  the  definition  of  the  state 
variable  is  given  along  with  the  defining  equation.  All  units 
should  be  clearly  defined.  The  initial  value  is  placed  in  the 
third  column. 

3.3. b.  System  attributes .  Figure  III— 1*  shows  the  use  of 
thevariables  form  for  defining  system  attributes.  The  system 
attributes  box  is  checked  in  the  section  labeled  "type  of  variables." 
The  system  attribute  name  is  entered  in  the  first  column  with  the 
index  number  in  parentheses.  The  definition  is  entered  in  the 
second  column.  If  the  definition  is  a  code  as  for  SA(5)t  the 
meaning  of  each  possible  code  value  should  be  defined.  The  initial 
value  is  entered  in  the  third  column.  System  attributes  are 
initialized  on  ISA  cards. 

3.3. c.  User  variables.  Figure  III-5  shows  the  use  of 
the  variables  form  for  defining  user  variables.  A  user  variable  is 
one  that  is  defined  by  the  user  and  referenced  only  in  user-written 
code.  It  may  or  may  not  be  placed  in  a  user  common  block.  The 
variable  name,  definition,  and  initial  value  are  placed  in  the  first 
three  columns .  The  common  block  name  where  the  variable  is  stored 
is  entered  in  the  last  column.  User  variables  should  be  entered 
alphabetically  or  sorted  by  common  block. 

The  three  types  of  variables  should  be  kept  separated  for 
easier  reference. 

3-U .  Monitors . 

All  SAINT  monitors  must  be  clearly  defined  on  the 
monitors  form.  An  example  showing  the  use  of  this  form  is  given  in 
Figure  III-6.  There  are  two  kinds  of  monitors:  SAINT  monitors  and 
USER  monitors.  SAINT  has  a  built-in  capability  to  detect  threshold 
crossings  and  take  appropriate  action.  These  are  referred  to  on 
the  form  as  SAINT  monitors,  and  they  are  discussed  in  references  [1] 
and  [2] .  Use  of  user  monitors  is  described  in  reference  [3] . 

The  monitor  number  and  label  are  entered  in  the  first  two 
columns,  and  the  type  of  monitor  (USER  or  SAINT)  is  entered  in  the 
third  column.  1  verbal  description  of  the  significance  of  the  moni¬ 
tor  is  entered  in  the  fifth  column  with  a  text  or  equation  represen¬ 
tation  of  the  threshold  crossing  conditions  in  the  fourth  column. 

The  action  to  be  taken  when  a  threshold  crossing  occurs  is  entered 
in  the  last  two  columns.  Under  CODE,  either  MTAS  or  MSWT  (or  both) 
are  entered,  followed  by  a  description  of  the  action  take;'. 


Each  task  node  in  the  SAIBT  model  vlll  be  described 
using  the  SAINT  Task  Description  fora.  An  example  shoving  the 
use  of  this  fora  is  given  in  Figure  III-7.  It  vould  be  advanta¬ 
geous  to  use  a  separate  sheet  (cr  sheets)  for  each  task  node  so 
that  they  can  easily  fee  sorted  by  task  number.  The  task  number 
is  entered  in  the  first  rolvasn,  followed  by  a  description  cf  the 
node.  The  description  will  define  what  task  (or  group  of  tasks) 
is  represented  by  the  tax*.  node.  Seme  discussion  should  be 
included  here  describing  the  subsequent  branching  from  the  node. 
Predecessor  and  subsequent  predecessor  requirements  should 
be  described  if  their  usage  is  net  clear.  Each  resource  required 
for  the  task  should  be  listed  and  described  under  the  heading 
RESOURCE  REQUIREMENTS . 

Each  task  descriptor  (except  RESR)  will  be  entered  under  the 
heading  DESCRIPTORS.  The  k-letter  descriptor  code  is  entered 
under  CODS.  The  remaining  descriptor  parameters  may  be  placer! 
under  MEANING,  but  they  may  be  left  off  this  for*  as  they  can  be 
referenced  in  the  SAIST  data  input  section.  The  aain  reason  for 
putting  descriptors  on  this  for*  is  to  verbally  describe  the  usage 
of  each  descriptor.  It  may  be  advantageous,  however,  to  list  the 
moderator  function  numbers  along  with  any  MCDF  descriptors. 

The  TECHNICAL  REFERENCES  column  is  for  listing  any  references 
which  were  used  in  defining  the  task  or  determining  the  task 
descripto  .*s . 

3-6 .  Statistics . 

SAINT  allows  a  great  deal  of  flexibility  in  the  genera¬ 
tion  of  both  task  statistics  and  user  collected  statistics.  (See 
references  [1,2].)  Since  the  task  statistics  are  collected  through 
the  use  of  the  STAT  descriptor  on  task  nodes,  the  collection  of 
task  statistics  will  be  documented  under  the  DESCRIPTOR  heading  of 
the  form  for  the  task  nodes .  For  user  statistics ,  the  form  shown 
in  Figure  III-8  will  he  used. 

Each  user  statistic  has  an  identification  number  which  is 
placed  in  the  second  column.  The  statistic  type  will  he  entered 
in  the  first  column.  One  of  the  following  codes  will  be  used  for 
statistic  type: 

Statistic  Type  Code  Meaning 


TPR 

Time  Persistent  Regular 

TPA 

Time  Persistent  Averaged 

OBS 

OBservation  Statistic 

HIST 

Histogram 

PLOT 

Plot 

F-22 


F-23 


Figure  III-7.  Sample  TASK  DESCRIPTIOH  Form 
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The  statistic  naae  vill  be  entered  in  the  third  column.  and 
a  description  of  the  statistic  vill  be  placed  in  the  fourth  column. 

A  verbal  description  of  hov  the  statistic  is  collected  and  reported 
is  entered  in  the  last  colisan.  This  vill  include  such  information 
as  vhat  subprogram  contain  the  appropriate  calls  to  the  user 
support  subprogram,  when  that  subprogram  is  called,  and  whether 
the  statistic  is  cleared  at  the  end  of  each  iteration  or  averaged 
over  all  iterations. 

3-7.  User  Functions. 

SAINT  nas  two  user-vritten  functions:  USER?  and  USEHIS. , 
Function  USER?  is  called  during  execution  whenever  the  UT  designa¬ 
tion  is  used  for  task  times  or  attribute  assignments  (see  references 
(1)  and  ( 2 } ) .  Function  USERI?I  is  used  only  for  initialization  of 
resource  or  system  attributes  on  ISA  or  IRA  cards  (see  reference  13)). 
The  fore  for  documenting  the  user  functions  is  shown  in  Figure  II1-9- 

The  box  next  to  the  appropriate  user  function  name  (USERIH  or 
USEPF)  should  be  checked,  and  separate  sheets  shculd  be  used  to 
keep  the  two  separate.  Each  user  function  number  will  be  entered  in 
the  first  column.  The  user  function  number  is  the  same  as  the  para¬ 
meter  value  passed  into  the  user  function.  Each  task  number  (USEF.F 
only)  where  the  user  function  is  called  is  listed  in  the  second 
column.  Under  the  DESCRIPTION  heading,  the  operations  performed 
by  that  user  function  are  described. 

All  of  the  user  function  numbers  should  be  in  ascending  order 
for  easy  reference. 

3-8 .  Moderator  Functions. 

The  use  of  moderator  functions  will  be  described  using 
the  form  shown  in  Figure  III-10.  The  moderator  function  numbers  are 
entered  :.n  the  first  column  in  ascending  order.  All  task  numbers 
referencing  the  moderator  function  ore  listed  in  the  second  column. 
Under  the  DESCRIPTION  column,  the  calculations  involved  in  the 
moderator  function  are  described.  In  the  last  column,  any  references 
which  were  used  in  determining  the  moderator  function  are  listed. 


b-0  USER-WRITTEN  SUBPROGRAMS . 

A  section  will  be  included  in  each  manual  describing  user- 
vriVcen  subprograms .  This  section  will  be  divided  into  three  sub¬ 
sections.  First,  an  index  page  will  list  all  user-written  sub¬ 
program  names .  A  standard  format  as  shown  in  Figure  III-ll  will  be 
used  for  this  index.  User-written  subprograms  will  be  divided  into 
two  groups:  standard  user-written  subprograms  and  additional  user- 
written  subprograms.  The  first  group  contains  what  are  referred 
to  as  "standard  user-written  subprograms."  These  are  called  directly 
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8AIHT  USER-WRITTEN  SUBPROGRAMS 

Check  all  Standard  User-Written  subprograms  that 
are  used  in  this  model.  Then  add  at  the  bottom  the 
names  of  other  user-vritten  subprograms. 


STANDARD  USER-WRITTEN  SUBPROGRAMS 

□ 

SUBROUTINE  ENDIT 

□ 

SUBROUTINE  INTLC 

□ 

SUBROUTINE  MODRF 

□ 

FUNCTION  PRIOR 

% 

□ 

SUBROUTINE  STATE 

□ 

SUBROUTINE  UACCPT 

□ 

SUBROUTINE  UERR 

□ 

SUBROUTINE  UINPT 

□ 

SUBROUTINE  USCOND 

□ 

FUNCTION  IJSERF 

□ 

FUNCTION  US ERIN 

□ 

SUBROUTINE  UOTPT 

— 

ADDITIONAL  USER-WRITTEN  SUBPROGRAMS 

' 

1 

1 

i 

Figure  III-ll.  Form  for  Indexing  User-Written  Subprograms. 
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by  SAUTT.  The  MOPADS  nodeler  will  simply  check  the  appropriate 
boxes  for  the  ones  which  are  included  in  the  model  being  docu¬ 
mented.  The  second  group  are  subprograms  that  are  called  by  sub¬ 
programs  in  the  first  group.  These  will  be  listed  in  alphabetical 
order  in  the  box  in  the  lower  part  of  the  form. 

The  index  page  will  be  followed  by  a  section  containing  des¬ 
criptions  of  the  user-written  subprograms.  These  descriptions 
should  include  the  subprogram  purpose,  parameter  definitions,  a 
discussion  of  what  the  subprogram  dees,  and  possibly  a  discussion 
of  the  flow-of-control  of  the  subprogram  cr  a  flowchart .  The  sub¬ 
program  descriptions  can  be  put  into  the  two  groups  (standard  and 
others)  and  then  alphabetized,  or  simply  alphabetized  as  a  single 
group. 


Following  the  subprogram  descriptions,  listings  for  all  of 
the  subprogram  will  be  included.  These  should  be  alphabetized  in 
the  same  way  as  the  subprogram  descriptions.  Extremely  lengthy 
lietings  may  be  bound  separately  if  a  reference  to  the  separate 
binding  document  is  given. 


5-0  LISTING  OF  SAINT  NETWORK  DATA  INPUT. 

A  listing  of  the  SAINT  data  input  statements  will  be  included 
here.  This  listing  will  start  with  the  GEN  card  and  end  with  a  FIN 
card  and  will  Include  all  task  nodes  and  network  elements  as  they 
are  represented  by  the  SAINT  data  cards. 


6-0  NON-SAINT  DATA  REQUIREMENTS. 

The  system  module  has  access  to  external  data  sources  through 
user-written  programs.  The  MOPADS  modeler  must  describe  in  this  sec¬ 
tion  any  data  requirements  of  the  module.  In  particular,  interaction 
with  the  MOPADS  data  base  must  be  described.  Information  in  this 
section  should  include: 

6-1.  Data  files  opened  and  closed  by  the  module.  This  in¬ 
cludes  requirements  for  pre-existing  files  and  files  created  by 
the  module.  Detailed  file  formats  will  be  given. 

6-2.  Interaction  with  the  MOPADS  data  base.  This  includes 
entries  which  must  be  created  in  the  data  base  prior  to  running  the 
module  and  those  created/destroyed  by  it  during  simulations. 

Details  of  the  information  transfer  must  be  given. 
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7-0  OUTPUT  REPORTS . 


This  section  will  include  an  index  of  all  SAINT  output  reports 
generated  for  the  air  defense  system  module,  followed  by  sample  out¬ 
puts  for  each  statistics  collected.  A  standard  form  will  be  used  for 


F-29 


'i' V-.  /  Sis*  ,; 


*.■'•>  •* 
.Vc} 


indexing  the  output  reports,  see  Figure  III-12.  The  uppermost 
box  contains  all  of  the  options  for  statistics  that  SAINT  will 
collect  automatically.  Simply  check  the  boxes  next  to  the  options 
used  for  the  system  module.  These  options  are  divided  into  tvo 
sections:  iteration  statistics  and  sum  ary  statistics.  The  iteration 
statistics  are  printed  out  at  the  end  of  each  iteration  for  a  speci¬ 
fied  range  of  iterations.  (These  options  and  start  and  end  itera¬ 
tions  are  indicated  on  the  OUT  card,  see  reference  (2),  pages  !»2-l»3.) 

The  summary  statistics  are  averaged  over  all  iterations  and  printed 

out  at  the  end  of  the  simulation.  For  each  option  checked,  enter 
a  section  number  in  the  right-hand  column.  The  section  number  can 
be  assigned  like  a  figure  number,  and  will  represent  the  location 
witnin  this  section  of  the  indicated  type  of  report.  For  example, 
in  Figure  III-12,  the  output  for  all  Resource  Utilisation  Statistics 
for  a  single  iteration  would  be  found  in  Section  VII-1. 
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The  bottom  half  of  the  form  in  Figure  III-12  will  he  used  to 
index  all  user  statistic  sample  outputs.  The  statistic  name, 
number,  and  whether  the  statistic  is  an  iteration  or  svmmary 
statistic,  is  entered  in  the  left-hand  column.  In  the  right-hand 
column  the  section  number  where  the  sample  output  iB  located  is 
entered.  Just  as  it  was  done  for  the  SAINT  statistics. 

Each  sample  output  with  explanation  will  be  included  in  the 
order  indicated  by  the  index.  For  iteration  statistics  collected 
for  more  than  one  iteration,  only  one  end  of  iteration  report  need 
be  included. 
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SAINT  OUTPUT  INDEX 


SAINT  OUTPUT  REPORTS 

Ksm 

ITERATION 

STATISTICS 

O  Detailed  Iteration  Reports 

S3  Resource  Utilization  Statistics 

53  Task  Statistics 

CD  State  Variable  Value  Outputs 

O  State  Variable  Statistics 

CD  State  Variable  Plots /Tables 

■ 

I 

SUVHARY 

STATISTICS 

ED  Resource  Utilization  Summary  Report 

CD  Statistics  Task  Summary  Report 

ED  Histograms  of  Task  Statistics,  Iteration  1 
CD  Histograms  of  Task  Statistics,  Summary 

SSflj 

USER  STATISTICS  OUTPUT  REPORTS 

SECTION  NO. 

1.  Observation  Statistics  1,  Summary 

2.  Plot  of  SS(3) .Plot  No.  1 

3.  Histogram  of  Statistic  2,  Iteration 

VII-6 

VII-7 

VII-8 

Figure  III-12,  Form  for  Indexing  the  SAINT  Output  Report  Samples. 


IV,  BLANK  FORMS 


This  section  contains  a  reduced  copy  of  the  following 
blank  forms . 

•  SAINT  ENTITIES 

•  SAINT  RESOURCES  i 

•  SAINT  VARIABLES 

•  SAINT  MONITORS  *  ! 

•  SAINT  TASK  DESCRIPTIONS 

•  SAINT  STATISTICS 

•  SAINT  USER  FUNCTIONS 

•  SAINT  USER-WRITTEN  SUBPROGRAMS 

• 


SAINT  OUTPUT  INDEX 


VARIABLE  DEFINITION  AND/OR  DEFINING  EQUATION  (usERWmSS'oNLV) 


J - L-J 
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TYPE  OF  VARIABLES;  □  STATE  VARIABLES  □ SYSTEM  ATTRIBUTES  [j  USER  VARIABLES 

MAME!  AIR  DEFENSE  SYSTEM  MODULE: 

DATE!  _  PROJECT:  _ _ _ 

SAINT  VARIABLES  page _ of_ 


AIR  DEFENSE  SYSTEM  MODULE: 
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DATE:  j  PROJECT; _ ~ 

SA1IJT  USER  FUNCTIONS  page! 


SAINT  USER-WRITTEN  SUBPROGRAMS 


Cheek  all  Standard  User-Written  subprograms  that 
are  used  in  this  model.  Then  add  at  the  bottom  the 
names  of  other  uaer-vritten  subprograms. 


STANDARD  USER-WRITTEN  SUBPROGRAMS 

□ 

.  SUBROUTINE  ENDIT 

□ 

SUBROUTINE  INTLC 

□ 

SUBROUTINE  MODRF 

□ 

FUNCTION  PRIOR 

□ 

SUBROUTINE  STATE 

□ 

SUBROUTINE  UACCFT 

□ 

SUBROUTINE  UEPR  } 

□ 

SUBROUTINE  UINPT 

□ 

SUBROUTINE  UT.COND 

□ 

FUNCTION  USERF 

□ 

FUNCTION  US ERIN 

□ 

SUBROUTINE  UOTPT 

ADDITIONAL  US  EH -WRITTEN  SUBPROGRAMS 
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SAINT  OUTPUT  INDEX 


SAIHT  OUTPUT  PEPORTS 

Section 

To. 

ITERATION 

STATISTICS 

O  Detailed  Iteration  Report* 

0  Resource  Utilitation  Statistics 

C  Task  Statistics 

Q  State  Variable  Value  Outputs 

G  State  Variable  Statistics 

O  State  Variable  Plots /Tables 

8 

►*  *■« 

1  6 

Z  H 

“  1 

□  Resource  Utilisation  Sumary  Report 

O  Statistics  Task  Summary  Report 

0  Histograms  of  Task  Statistics,  Iteration  1 
0  Histograms  of  Task  Statistics,  Summary 

USER  STATISTICS  OUTPUT  REPORTS 

SECTION  BO. 
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STANDARD  MOPADS  TERMINOLOGY 


AIR  DEFENSE  SYSTEM 

A  component  of  Air  Defense  which  includes  equipment  and 
operators  and  for  which  technical  and  tacticel  tr pining 
are  required.  Examples  axe  TBAWK  and  the  AN/TSQ-73. 

AIR  DEFENSE  SYSTEM  MODULE 

Models  of  operator  actions  and  equipment  characteristics 
for  Air  Defense  Systems  in  the  MOPADS  software.  These 
models  are  prepared  with  the  SAINT  simulation  language. 

Air  Defense  System  Modules  include  the  SAINT  model  and 
all  data  needed  to  completely  define  task  element  time, 
task  sequencing  requirements , and  human  factors  influences. 

AIR  SCENARIO 

A  spatial  and  temporal  record  of  aerial  activities  and 
characteristics  of  an  air  defense  battle.  The  Air  Scenario 
includes  aircraft  tracks,  safe  corridors,  ECM,  and  other 
aircraft  and  airspace  data.  See  also  Tactical  Scenario. 

BRANCHING 

A  term  us'd  in  the  SAINT  simulation  language  to  mean  the 
process  by  which  TASK  nodes  are  sequenced.  At  the  comple¬ 
tion  of  the  simulated  activity  at  a  TASK  node,  the  Branching 
from  that  node  determines  which  TASK  nodes  will  be  simulated 
next . 

DATA  BASE  CONTROL  SYSTEM 

That  part  of  the  M0PAD§  software  which  performs  all  direct 
communication  with  the  MOPADS  Data  Base.  All  information 
transfer  to  and  from  the  data  base  is  performed  by  invoking 
the  subprograms  which  make  up  the  Data  Base  Control  System. 

DATA  SOURCE  SPECIALIST 

A  specialist  in  obtaining  and  interpreting  Army  documentation 
and  other  data  needed  to  prepare  Air  Defense  System  Modules. 

ENVIRONMENTAL  STATE  VARIABLE 

An  element  of  an  Environmental  State  Vector. 
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I. 


INTRODUCTION 


A  major  part  of  the  MOPADS  software  will  he  the  individual 
system  modules.  These  modules  will  be  SAINT  models  of  various 
air  defense  systems,  such  as  the  AN/TSQ-73,  which  together  form 
air  defense  configurations.  As  new  equipment  is  developed,  new 
system  modules  will  be  added  to  the  MOPADS  software.  The  metho¬ 
dology  for  developing  these  system  modules  is  provided  here. 

System  module  development  will  involve  two  major  types  of 
activities:  1)  SAINT  modeling,  and  2)  data  collection.  The  data 
collection  activities  will  involve  locating  and  obtaining  documents, 
identifying  pertinent  information  within  those  documents,  locating 
subject  matter  experts  and  experienced  operators ,  and  getting 
pertinent  information  from  those  experts.  SAINT  modeling  will  invo’ 
taking  the  pertinent  information  and  using  it  to  create  a  SAINT 
model.  The  SAINT  model,  with  its  accompanying  parameters  and  inter¬ 
faces  to  the  MOPADS  software  system,  is  referred  to  as  an  air  defense 
system  module.  The  modeling  activities  will  be  performed  by  one 
or  more  SAINT  modelers  with  Operations  Research  experience  and 
expertise.  It  is  expected  that  the  MOPADS  model er(s)  will  receive 
help  in  performing  the  data  collection  activities  from  a  Data  Source 
Specialist.  This  person  (or  persons)  must  be  experienced  in  Army 
documentation  and  air  defense  systems. 

A  CFM  (or  PERT)  chart.  Figure  II-l,  was  developed  to  show  the 
breakdown  of  activities  and  precedence  relationships.  The  data 
collection  activities  are  distinguished  from  the  SAINT  modeling 
activities  by  using  dashed  lines  for  the  data  collection  activities. 
Figure  II-l  is  described  in  detail  in  Section  II. 

In  Section  III,  each  task  shown  on  the  CFM  chart  is  described 
in  further  detail.  Blank  forms  to  be  used  in  performing  some  of 
these  tasks  are  given  in  Section  IV.  The  SAINT  modeler  should  collect 
and  compile  these  forms  and  keep  them  in  a  notebook.  All  forms  of 
a  given  type  should  be  kept  together,  and  the  groups  of  forms 
should  be  ordered  in  the  same  order  as  the  forms  are  presented  in 
Section  IV. 


(Blank  Page) 


II.  CPU  CHART 
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1-0  DESCRIPTION 

The  CPM  (Critical  Path  Method)  chart  for  system  module 
development  is  shown  in  Figure  II-l.  It  is  a  project  management 
chart  showing  all  of  the  activities  on  the  lines  of  the  network. 

The  nodes  (circles)  represent  milestones  in  the  project.  The  flow 
of  the  network  goes  from  left  to  right.  Every  activity  (represented 
by  a  line)  going  into  a  node  must  be  completed  before  any  activities 
coming  out  of  the  node  can  be  started.  If  more  than  one  activity 
enters  a  node,  the  last  activity  completed  will  determine  the  start 
time  of  any  outgoing  activities.  The  longest  path  through  the 
network  is  referred  to  as  the  critical  path.  Any  delays  in  activ¬ 
ities  along  the  critical  path  result  in  delays  in  the  project,  whereas 
delays  in  non-critical  activities  may  or  may  not  delay  the  project 
completion.  The  bold  solid  (or  dotted)  line  in  Figure  II-l  represents 
the  expected  critical  path,  individual  circumstances  or  manpower 
shortages  may  change  the  critical  path,  but  the  activity  precedence 
relationships  would  still  hold.  Dotted  lines  represent  data  collec¬ 
tion  activities,  while  solid  lines  represent  SAINT  modeling  activities. 

Each  activity  on  the  CPM  network  is  given  a  two  part  identifying 
number.  The  "1."  numbers  represent  SAINT  modeling  activities,  while 
the  "2."  numbers  represent  data  collection  activities.  Each  activity 
is  explained  in  detail  in  Section  III. 

The  activities  contained  in  the  CPM  chart  are  divided  into 
four  groups .  These  ere  shown  with  the  large  braces  along  the  bottom 
of  the  chart  in  Figure  II-l.  The  activity  groupings  are  defined  below. 

1-1.  Operator  and  Equipment  Definition.  During  this  phase 
of  the  project,  the  operator  duties  and  equipment  requirements  are 
characterized. 

1-2.  Task  Definition.  A  task  is  defined  as  a  sequence  of 
task  elements  (such  as  pushing  a  button)  which  accomplishes  some 
purpose.  During  this  phase  of  the  project,  the  tasKS  performed 
during  normal  operations  of  the  equipment  are  identified,  listed,  and 
characterized. 
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1-3 •  Command  and  Control  and  Task  Sequencing  Definition. 
During  this  phase  of  the  project,  the  decision  processes  for  seq¬ 
uencing  tasks  are  characterized.  This  involves  understanding  the 
operators’  interaction  vith  other  air  defense  components. 

1-1* .  SAINT  Model  Implementation  and  Documentation.  The 
task  sequencing  submodel  and  task  performance  models  will  be  dis¬ 
aggregated  to  the  desired  level  of  fidelity.  Ae  model  vill  be 
integrated  vith  the  MOPADS  software  and  required  documentation 
vill  be  completed. 
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III. 


ACTIVITY  DESCRIPTIONS 


1-0  SAINT  MODELING  ACTIVITIES . 

1-1 .  Operator  and  Equipment  Definition. 

Activity  1.3  As  early  as  possible  the  MOPADS  modeler 
should  receive  a  brief  demonstation  of  the  equipment  operation.  Hie 
modeler  need  not  develop  a  working  understanding  of  the  operation 
at  this  state.  This  demonstration's  purpose  is  to  give  the  modeler 
a  general  understanding  of  what-  the  equipment  does  and  how  it  is 
operated. 


Activity  1.2  The  SAINT  modeler  will  have  a 
list  of  references  to  documentation  describing  the  overall 
system,  operator  responsibilities,  and  equipment.  From 
this  documentation  the  SAINT  modeler  will,  construct  three 
lists . 


1.  The  first  list  will  contain  all  equipment  components 
that  are  essential  for  the  operators  to  perform  their  tasks.  List 
equipment  which  may  have  a  status  such  as  "operational,"  "partially 
operational,"  or  ”non-operaticnal. "  If  a  piece  of  equipment  may 
degrade  or  break  down,  and  this  would  have  an  effect  on  the  operator 
task  performance,  then  that  piece  of  equipment  should  be  included 
in  this  list.  The  equipment  list  will  be  used  to  assign  SAINT 
resources  and  to  characterize  operator  tasks.’  No  standard  form  has 
been  developed  for  listing  pertinent  equipment.  The  list -will- 
in  elude  the  component  name,  accompanied  by  a  short  description  of 
its  function. 


2.  The  second  list  will  identify  the  operators  of  the 
air  defense  system.  A  form  has  been  created  to  list  the  operators, 
and  a  sample  of  this  form  is  ihown  in  Figure  III-l.  Each  operator 
will  be  assigned  an  identification  number  which  is  entered  in  the  first 
column.  The  operator  title  is]  entered  in  the  second  column.  The 
mission  and  duties  of  each  operator  are  described  in  the  third  column, and 
the  equipment  used  by  each  operator  in  performing  his  duties  is 
listed  in  the  fourth  column.  These  equipment  designations  should 
correspond  to  those  in  the  above  mentioned  equipment  list. 

Sometimes  an  air  defense  system  may  have  different  configura¬ 
tions  of  operators  such  as  two  officers  or  one  officer  and  one 
enlisted  person.  In  this  case  a  decision  must  be  made  concerning  the 
number  of  options  to  be  modeled.  A  standard  or  most  likely  configura¬ 
tion  may  be  selected,  or  multiple  configurations  with  user  specified 
options  may  be  selected.  In  the  latter  case  it  may  be  required  to  develop 
several  sets  of  the  documents  described  subsequently,  one  for  each  option. 
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Figure  III-l.  Sample  OPERATOR  DEFINITIONS  Form 


3.  The  third  list  to  be  produced  is  a  list  of  cate¬ 
gories  for  all  the  tasks  performed  by  each  operator.  Some  typical 
categories  are  tracking,  target  acquisition,  TEWA,  and  target  identi¬ 
fication.  The  number  of  these  categories  will  normally  oe  less  than 
ten.  Scm*  tasks  may  be  placed  under  more  than  one  category.  It  is 
not  necessary  to  assign  tasks  to  categories  at  this  time;  the  task 
categories  need  on?y  be  defined  here. 

The  documentation  on  these  subjects  may  not  be  complete 
enough  to  allow  the  MOPADS  modeler  to  successfully  complete  this 
activity.  If  so  the  modeler  may  want  to  consult  subject  matter 
experts  or  experienced  operators  to  obtain  more  complete  information. 

It  may  be  desirable  to  consult  such  experts  even  if  the  documentation 
is  considered  thorough.  In  this  way,  the  modeler  may  obtain 
additional  confidence  in  the  lists  produced  during  this  activity. 

1-2.  Task  Definition. 

Activity  1.3  There  may  be  more  than  one  way  that  the 
system  can  be  configured.  In  this  case,  those  configurations  to  be 
modeled  must  be  selected.  A  diagram  showing  the  chosen  configuration 
and  how  it  interfaces  with  the  overall  AD  system  should  be  drawn  for 
later  reference.  If  more  than  one  configuration  is  selected,  it  may 
be  required  to  develop  multiple  models.  A  decision  must  be  made  as  to 
whether  it  is  more  economical  to  model  the  system  as  a  single  module 
or  as  separate  modiii.es. 

Activity  1.4  At  this  point,  a  list  of  tasks  will  have 
been  completed.  This  list  will  give  references  to  the  documentation, 
the  operator  performing  the  task,  and  which  group  the  task  is  in. 

The  MOPADS  modeler  will  carefully  examine  this  list  to  determine  if 
any  tasks  have  been  left  out  or  if  sane  of  the  tasks  may  be  removed 
from  the  list. 

Activity  1  ■  5  Based  on  the  operator  and  equipment  defini¬ 
tions  ,  the  MOPADS  modeler  will  decide  whether  to  model  each  operator 
as  an  entity  or  resource,  and  which  equipment  to  model  explicitly  as 
resources .  The  forms  shown  in  Figures  III-2  and  III- 3  are  filled 
out  at  this  time  [1] . 

Activity  1.6  The  task  list  will  have  been  finalized  and 
nominal  task  times  will  have  been  determined.  Based  on  the  task  list 
and  the  entity  and  resource  definitions,  the  modeler  will  develop 
aggregate  SAINT  models( perhaps  single  task  nodes)  for  each  task.  Final 
statistics,  priorities,  etc.  will  not  be  needed  at  this  time. 

A  standard  form  is  available  for  creating  these  aggregated 
models.  A  sample' is  shown  in  Figure  111-4.  The  information  on  this 
form  is  taken  from  the  task  list  which  is  completed  during  Activities 
2.4  and  2.5.  No  branching  or  precedence  relationships  to  and  from  the 
task  will  be  included  at  this  time. 
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1-3.  Command  and  Control  and  Task  Sequencing  Definition. 


Activity  1.7  Once  the  operator  tasks  have  been  identi¬ 
fied,  the  MOPADS  modeler  needs  +o  view  the  equipment  in  operation. 

The  modeler  should  obtain  an  understanding  of  the  operators'  task 
sequencing  decisions  and  their  comnmnication  procedures. 

Activity  1.8  The  MCPADS  modeler  will  examine  appro¬ 
priate  sections  of  the  documentation  in  order  to  better  understand 
how  the  operators  go  from  one  task  to  another.  The  modeler  should 
understand  how  the  operators  sequence  their  tasks  in  order  to  maxi¬ 
mize  their  goal  (or  mission)  achievement. 

Activity  1.9  It  is  expected  that  each  of  the  system 
modules  will  have  a  similar  structure.  A  schematic  network  of  this 
basic  structure  is  shown  in  Figure  III-5.  The  operator  arrives  at 
the  task  sequencing  submodel.  This  may  be  only  one  task  node  or  a 
series  of  task  nodes.  The  purpose  of  the  task  sequencing  submodel 
is  to  determine  what  task  the  operator  performs  next .  The  operator 
branches  to  the  appropriate  task  node  (or  sequence  of  task  nodes), 
then  returns  to  the  task  sequencing  submodel  to  repeat  the  process. 

During  Activity  1.9  the  modeler  will  develop  a  pre¬ 
liminary  version  of  the  task  sequencing  submodel. 

Activity  1.10  The  modeler  will  integrate  the  deci¬ 
sion  submodel  with  the  aggregate  task  models  to  form  a  basic  SAINT 
model.  This  aggregate  model  will  be  run  to  verify  the  logic  con¬ 
tained  in  the  task  sequencing  submodel. 

1-U .  SAINT  Model  Implementation  and  Documentation. 

Activity  1.11  At  this  point ,  the  MOPADS  modeler  will 
have  a  large  amount  of  information  on  system  status ' ,  system  con¬ 
ditions ,  trial  drills,  alerts,  messages,  and  interrupting  and  non¬ 
interrupting  cues.  The  task  sequencing  submodel  will  be  expended 
to  incorporate  interrupt  features  so  the  module  can  ultimately  be 
integrated  with  the  command  and  control  elements  of  the  MOPADS  software. 

Activity  1.12  At  this  point,  the  task  sequencing  portion 
of  the  SAINT  network  will  be  well  defined,  but  the  task  models  will 
still  be  aggregated.  Many  of  these  task  models  will  be  expanded  into 
subnetworks  of  task  nodes  representing  the  flowchart  for  that  task. 

This  subnetwork  will  normally  have  only  one  input  and  one  output  branch 
(to  and  from  the  task  sequencing  submodel),  but  it  may  have  complex 
branching  within  it. 

It  is  expected  that  not  all  aggregated  task  models  will  require 
disaggregation.  Some  modeler  judgement  will  be  required  here  to  deter¬ 
mine  which  tasks  to  disaggregate  and  how  detailed  a  breakdown  is  necessary. 

This  activity  is  expected  to  be  the  most  time  consuming  of  all 
activities  in  the  system  module  developemnt  process. 


G-21 


Activity  1.13  At  this  point,  the  SAINT  network  for 
the  module  will  have  been  determined.  Now  the  MOPADS  modeler  must 
address  the  human  factors  aspects  of  the  model.  A  generalized  modera¬ 
tor  function  will  be  provided  as  part  of  the  MOPADS  software  which 
requires  as  input  a  list  of  skills  necessary  to  perform  each  task  or 
task  element  and  the  relative  weights  for  the  skills.  The  modeler 
must  provide  this  data  for  each  task  node. 

Activity  l.lfr  The  task  sequencing  submodel  will  have  asso¬ 
ciated  moderators  which  require  parameters  that  determine  the  operators’ 
goal  seeking  procedures.  These  will  be  determined  and  entered  into 
the  MOPADS  data  base.  This  will  complete  the  development  of  the 
task  sequencing  submodel. 

Activity  1.1$  Most  output  statistics  will  be  optional 
and  will  be  obtained  through  the  MOPADS  data  base.  However,  it  is 
required  that  certain  statistics  be  specified  on  the  SAINT  network. 

These  standard  statistics  will  be  entered  into  the  model  here.  They 
may  be  SAINT  task  statistics  or  user-created  statistic? 

Activity  l.l6  The  MOPADS  modeler  will  have  retained  a 
complete  list  of  task  times  for  all  SAINT  task  nodes  in  the  network. 

These  will  be  entered  into  the  MOPADS  data  base  for  reference  by  all 
SAINT  task  nodes.  Any  other  required  parameters  will  be  entered  into 
the  MOPADS  data  base. 

Activity  1.17  The  system  module,  now  in  its  final  form, 
is  ready  for  final  testing  and  debugging.  This  will  be  done  by  run¬ 
ning  the  model  alone  with  the  MOPADS  software  but  no  other  system 
modules,  if  this  is  possible.  If  noti  the  modeler  will  run  the  new 
system  module  interfaced  with  a  likely  configuration  containing  other 
system  modules . 

Activity  1.18  In  reference  1,  the  documentation  require¬ 
ments  for  MOPADS  system  modules  are  outlined  and  explained.  Several 
forms  are  provided  for  the  modeler  to  complete  while  the  module  is  being 
developed  which  will  become  part  of  the  documentation.  This  "documen¬ 
tation  during  development"  approach  will  ensure  completeness  and  reduce 
the  end-of-project  documentation  chores. 

Activity  1.19  Much  of  the  documentation  has  been  com¬ 
pleted  while  the  module  was  being  developed.  The  only  remaining 
activity  is  to  complete  the  documentation  and  put  it  in  its  final 
form  per  the  instructions  contained  in  reference  1. 


2-0  DATA  COLLECTION  TASKS. 

2-1 .  Operator  and  Equipment  Definition. 

Activity  2.1  Once  the  decision  has  been  made  as  to 
■what  equipment  is  to  be  modeled,  pertinent  documentation  describing 
the  operation  will  be  obtained.  This  may  include  Field  Manuals, 
Soldier's  Manuals,  Technical  Manuals,  and  any  other  documents  that 
may  exist.  LOAPs  may  be  used  in  locating  pertinent  document  titles. 

Activity  2.2  A  quick  look  through  the  documentation 
will  be  made  and  all  references  to  discussions  of  the  equipment  and 
individual  responsibilities  of  the  operators  should  be  noted.  A  list 
will  be  made  giving  ranges  of  page  numbers  for  later  reference.  AI30, 
references  to  discussions  of  the  overall  system  will  be  listed.  Any 
references  to  task  groupings  should  be  especially  noted. 

2-2.  Task  Definition - 

Activity  2.3  At  this  time,  the  form  shown  in  Figure  III-l 
will  have  been  completed  so  the  operators  to  be  modeled  will  have  been 
identified.  Also,  a  list  of  task  groups  and  a  list  of  equipment  the 
operators  will  run  will  have  been  developed.  Once  this  information  is 
complete,  the  task  list  can  be  developed.  In  order  to  develop  this 
task  list,  the  form  showr  in  Figure  III-6  is  provided.  A  good  place  to 
start  is  in  the  corresponding  Soldier's  Manuals  for  the  appropriate 
operators.  More  accurate  task  information  may  be  obtain  from  the  DTD. 

An  example  listing  of  a  task  is  shown  3n  Figure  III-6.  A  task 
number  must  be  assigned  to  each  task,  and  this  is  placed  in  the  first 
column.  The  task  name  is  entered  in  the  second  column.  All  references 
to  descriptions  and/or  flowcharts  for  the  task  aie  listed  in  the  third 
column.  These  would  normally  include  a  reference  to  the  Soldier's 
Manual  and/or  a  reference  to  the  Technic  til.  Manual .  All  references 
should  give  the  date  of  the  publication  ar.d  the  latest  change  number. 

Information  in  the  fotirth,  fifth,  and  sixth  columns  will  ref¬ 
erence  the  operator,  equipment,  and  task  grouping  lists  which  were 
developed  during  Activity  1.2  Information  necessary  to  fill  in  these 
three  columns  should  come  from  the  documentation  or  from  subject  matter 
experts  at  DTD.  Experienced  operators  may  also  be  consulted. 

The  far  right  column  is  left  blank  during  the  completion  of 
Activity  2.3,  unless  the  information  is  easily  attainable  at  this  time. 

Activity  2.U  The  task  list  will  have  been  reviewed 
and  revised  to  assure  that  no  critical  tasks  were  left  out  and  to 
remove  those  tasks  which  will  not  be  included  rr  the  system  module. 

Now,  the  task  list  is  finalized. 
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Figure  III-6,  Sample  TASK  DEFINITIONS  Fora 


Once  the  task  list  contains  all  appropriate  tasks,  the 
time  estimates  are  added  in  the  far  right  column  of  the  task  descrip¬ 
tion  forms.  This  time  estimate  will  he  obtained  from  equipment 
drills,  expert  estimation,  or  DTD  documentation.  These  time  esti¬ 
mates  may  be  constants  (i.e.,  5  minutes)  or  distributions  with 
parameters  (i.e.,  Normal  Distribution,  y  *  .5,  C  *  .15,  min  *  .2, 
max  *  .8) . 

Activity  2.5  A  list  will  be  made  of  all  references 
to  sections  in  the  documentation  describing  command  and  control 
systems  and  procedures.  Also,  discussions  of  how  the  operators 
function  in  the  command  and  control  system  should  be  referenced. 

This  list  will  give  ranges  of  page  numbers  for  sections  in  the  docu¬ 
mentation  describing  these  topics.  Any  discussions  of  how  the 
operators  sequence  their  tasks  should  be  referenced. 

2-3.  Command  and  Control  and  Task  Sequencing  Definition. 

Activity  2.6  All  system  conditions  will  be  defined 
using  the  form  shown  in  Figure  III-7-  A  system  condition  is  a  state 
of  alert.,  warning  status,  readiness  condition,  or  rule  of  engagement 
that  has  more  than  one  code  or  status  value.  They  are  normally  set 
by  higher  levels  of  command  and  communicated  to  the  appropriate  air 
defense  systems.  The  condition  name  and  definition  are  entered  in  the 
first  two  columns.  In  the  third  and  fourth  columns,  each  code  value  is 
listed  and  defined.  In  the  fifth  column,  the  person  or  command  center 
responsible  for  determining  the  current  code  value  is  listed.  In  the 
last  column,  the  way  in  which  the  operators  are  made  aware  of  code 
changes  for  the  alert  is  described. 

Also,  as  a  part  of  this  task  all  system  status  conditions  are 
defined.  A  status  may  be  the  fire  unit  status,  the  condition  of 
certain  equipment,  or  the  availability  of  a  resource.  A  form  has  been 
developed  to  perform  the  task  of  defining  status,  and  an  example  is 
shown  in  Figure  III-8.  In  the  first  column,  the  equipment  for  which 
the  status  applies  is  entered.  This  may  be  general  such  as  the  whole 
IHAWK  system  or  more  specific  such  asaTDECC  panel  or  launcher.  The 
name  of  the  status  and  definition  are  entered  in  the  second  and  third 
column.  Each  possible  value  (or  code)  is  entered  in  the  fourth  column 
along  with  its  meaning  in  the  fifth  column.  If  the  status  value  is 
simply  a  number  representing  a  level  of  some  resource,  this  should  be 
noted  here.  The  wav  in  which  status  values  are  communicated  is  des¬ 
cribed  in  the  last  column.  This  communication  may  he  either  upward 
or  downward  in  the  chain  of  command. 

Activity  2.7  The  operation  of  air  defense  equipment 
usually  involves  waiting  for  various  messages  or  cues  to  act  and  then 
taking  appropriate  action.  Certain  symbols,  codes,  and  messages  may 
appear  cn  a  radar  tracking  screen,  and  these  would  be  considered  cues 
to  act.  Some  cues  require  immediate  action  while  other  cues  do  not. 
These  are  referred  to  as  interrupting  and  non-interrupting  cues, 
respectively.  Cues  will  be  listed  using  the  form  shown  in  Figure  III-9. 
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Figure  III-8.  Sample  SYSTEM  STATUS  Form 
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The  operator  responding  to  the  cue  is  entered  in  the  first 
column.  A  description  of  the  cue  is  entered  in  the  second  column. 
In  the  third  column,  an  I  or  H  is  entered  to  designate  it  as  an 
interrupting  or  non-interrupting  cue.  The  subsequent  actions  per¬ 
formed  to  handle  the  situation  are  described  and/or  listed  in  the 
fourth  column.  This  would  normally  be  a  reference  to  one  or  more 
tasks  in  the  task  list.  In  the  far  right  column,  the  priority  for 
subsequent  action  is  described.  This  may  include  such  information 
as  which  tasks  would  be  pre-empted  by  this  action  and  which  tasks 
would  not  be  pre-empted. 

Three  possible  approaches  may  be  taken  in  obtaining  the 
information  necessary  to  fill  out  the  form  shown  in  Figure  III-9 

1.  A  Technical  Manual  may  exist  for  the  air  defense 
system  containing  alert  definitions.  For  example,  see  [2]  for  the 
AH/TSQ-73.  If  so,  this  would  be  a  good  place  to  start  obtaining 
information  on  operator  cues  to  act. 

2.  The  forms  shown  in  Figure  III-9  is  used  to  list 
only  the  cues  in  the  second  column.  The  rest  of  the  form  is 
left  blank  at  first.  The  cues  could  be  obtained  from  lists  of 
symbols,  alerts,  or  messages  as  contained  in  the  documentation,  or 
from  subject  matter  experts.  This  list  of  cues  is  given  to  an 
experienced  operator  or  subject  matter  expert  to  fill  in  the  sub¬ 
sequent  actions  for  each  cue  to  act.  The  system  module  task  list 
should  be  given  to  them  so  the  subsequent  actions  column  may  also 
be  filled  in. 


3.  The  fourth  column  of  the  form  shown  in  Figure  III-9 
may  be  filled  in  with  each  task  name  from  the  task  list.  With 
only  column  four  filled  out,  the  forms  are  then  given  to  a  subject 
matter  expert  or  experienced  operator,  who  would  fill  in  the 
corresponding  cue  (or  cues)  to  act  for  each  task  listed. 

A  combination  of  these  approaches  may  be  used  in  performing 
Activity  2.7. 

Activity  2.8  Examples  outlining  every  task  that  was 
performed  during  equipment  drills  should  be  obtained.  If  these  are 
not  available,  references  to  documentation  of  example  scenarios 
should  be  found.  These  should  show  actual  task  sequencing  performed 
by  experienced  operators . 

2-1*.  SAINT  Model  Implementation  and  Documentation. 

Activity  2.9  Nominal  times  for  each  task  element 
(SAINT  task  node)  axe  determined.  This  data  may  be  obtained  from 
equipment  drills,  subject  matter  experts,  or  computerized  scenario 
traces.  It  may  be  necessary  to  obtain  a  consensus  on  the  task 
times  from  several  different  sources. 
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1-0  STANDARD  MOPADS  TERMINOLOGY 


AIR  DEFENSE  SYSTEM  A  component  of  Air  Defense  which  includes 

equipment  and  operators  and  for  which  techni¬ 
cal  and  tactical  training  are  required. 
Examples  are  IHAWK  and  the  AN/TSQ-T3. 


AIR  DEFENSE  SYSTEM  Models  of  operator  actions  and  equipment 
MODULE  characteristics  for  Air  Defense  Systems  in 

the  MOPADS  software.  These  models  are  pre¬ 
pared  with  the  SAINT  simulation  language. 

Air  Defense  System  Modules  include  the  SAINT 
model  and  all  data  needed  to  completely 
define  task  element  time,  tank  sequencing 
requirements,  and  human  factors  influences. 


AIR  SCENARIO  A  spatial  and  temporal  record  of  aerial 

activities  and  characteristics  of  an  air 
defense  battle.  The  Air  Scenario  includes 
aircraft  tracks,  safe  corridors,  ECM,  and 
other  aircraft  and  airspace  data.  See  also 
Tactical  Scenario. 


BRANCHING  A  term  used  in  the  SAINT  simulation  language 

to  mean  the  process  by  which  TASK  nodes  are 
sequenced.  At  tne  completion  of  the  simulated 
activity  at  a  TASK  node,  the  Branching  from 
that  node  determines  which  TASK  nodes  will  be 
simulated  next. 


That  part  of  the  MOPADS  software  which  performs 
all  direct  communication  with  the  MOPADS  Data 
Base.  All  information  transfer  to  and  from 
the  data  base  is  performed  by  invoking  the  sub¬ 
programs  which  make  up  the  Data  Base  Control 
System. 


DATA  SOURCE  A  specialist  in  obtaining  and  interpreting 

SPECIALIST  Army  documentation  and  other  data  needed  to 

prepare  Air  Defense  System  Modules. 


ENVIRONMENTAL  An  element  of  an  Environmental  State  Vector. 

STATE  VARIABLE 


DATA  BASE  CONTROL 
SYSTEM 


* 


ENVIRONMENTAL 

STATE  VECTOR 

An  array  of  vain 
characteristics 
operator.  Eleme 
Vectors  may  chan 
simulation  to  re 
ment  conditions J 

.es  representing  conditions  or 
that  may  affect  more  than  one 
ntB  of  Environmental  State 
ge  dynamically  during  a  MOPADS 
present  changes  in  the  environ- 

MODERATOR  FUNCTION 

I 

|  __ . 

A  mathematical /I 
alters  the  nomill 
activity  (usual! 
time  is  changed 
capability  to  pi 
Operator's  State 

.ogical  relationship  which 
ial  time  to  perform  an  operator 
y  a  Task  Element).  The  nominal 
to  represent  the  operator's 
■rform  the  activity  based  on  the 
(  Vector. 

MOPADS  DATA1  BASE 

A  computerized  data  base  designed  specifically 
to  support  the  MOPADS  software.  The  MOPADS 
Data  Base  contains  Simulation  Data  Set(s).  It 
communicates  interactively  with  MOPADS  Users 
during  pre-  and  post-run  data  specification  an# 
dynamically  with  the  SAINT  software  during 
simulation. 

MOPADS  MODELER 

An  analyst  who  will  develop  Air  Defense  System 
Modules  and  modify /develop  the  MOPADS  software 
system. 

* 

MOPADS  USER 

An  analyst  who  will  design  and  conduct  simu¬ 
lation  experiments  with  the  MOPADS  software. 

MSAINT(MOPADS/SAINT) 

1,, 

The  variant  of  SAINT  used  in  the  MOPADS  system 
The  standard  version  of  SAINT  has  been  aodifie 
for  MOPADS  to  permit  shareable  subnetworks  and 
more  sophisticated  interrupts.  The  terms  SAIN 
and  MSAIHT  are  used  interchangeably  when  no 
confusion  will  result.  See  also,  SAINT. 

OPERATOR  STATE 

VARIABLE 

1 

One  element  of  an  Operator  State  Vector. 

OPERATOR  STATE  An  array  of  values  representing  the  condition 

VECTOR  and  characteristics  of  an  operator  of  an  Air 

Defense  System.  Many  values  of  the  Operator 
State  Vector  will  change  dynamically  during 
the  course  of  a  MOPADS  simulation  to  represenl 
changes  in  operator  condition. 


I 
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OPERATOR  TASK 


An  operator  activity  identified  during 
weapon*  sy.tem  front-end  analyse*. 


ii 

V 

i 

» 

'  • 

SAINT 

The  underlying  computer  simulation  language 
used  to  model  Air  Defense  Systems  in  Air 

Defense  System  Modules.  SAINT  is  an  acronym 
for  Systems  Analysis  of  Integrated  Networks  of 
Tasks.  It  is  a  well  documented  language  designet 
specifically  to  represent  human  factors  aspects 
of  man/machine  systems.  See  also  MSAINT. 

SIMULATION  DATA  SET 

The  Tactical  Scenario  plus  all  required  simu¬ 
lation  initialization  and  other  experimental 
data  needed  to  perform  a  M0PAD6  simulation. 

SIMULATION  STATE 

At  any  instant  in  time  of  a  MOPADS  simulation 
the  Simulation  State  is  the  set  of  values  of  all 
variables  in  the  MOPADS  software  and  the  MOPADS 
Data  Base. 

SYSTEM  MODULES 

See  Air  Defense  System  Modules. 

i 

TACTICAL  SCENARIO 

The  Air  Scenario  plus  specification  of  critical 
assets  and  the  air  defense  configuration 
(number,  type  and  location  of  weapons  and  the 
command  and  control  system). 

■ 

TACTICAL  SCENARIO 

An  clem,  t  of  a  Tactical  Scenario,  e.g.,  if  a 

..a. 

COMPONENT 

Tactical  Scenario  contains  several  Q-T3's,  each 
one  is  a  Tactical  Scenario  Component. 

• 

TASK 

See  Operator  Task. 

Individual  operator  actions  which,  when  grouped 
appropriately,  make  up  operator  tasks.  Task 
elements  are  usually  represented  by  single 
SAINT  TASK  nodes  in  Air  Defense  System  Modules. 


TASK  ELEMENTS 


» 


L  \ 


i 


TASK  NODE 

A  modeling  symbol  used  in  the  SAINT  simulation 
language.  A  TASK  node  represents  an  activity; 
depending  upon  the  modeling  circumstances,  a 
TASK  node  may  represent  an  individual  activity 
such  as  a  Teak  Element,  or  it  may  represent  an 
aggregated  activity  such  as  an  entire  Operator 
Task. 

TASK  SEQUENCING 
MODERATOR  FUNCTION 

A  mathematical/logical  relationship  vhich 
selects  the  next  Operator  Task  vhich  an 
operator  will  perform.  The  selection  is  baaed 
upon  operator  goal  seeking  characteristics. 

2-0  OTHER  TERMINOLOGY 

AIRCRAFT  CHECKPOINTS 

The  aircraft  paths  in  MOPADS  air  scenarios 
are  assumed  to  be  piecewise  linear  paths. 

The  points  where  the  aircraft  speed  and/or 
heading  change  are  called  checkpoints. 

ASO 

Azimuth  Speed  Operator  -  the  operator  in  the 
IBAWK  system  responsible  for  detecting  low 
flying  approaching  aircraft. 

BCC 

Battery  Control  Central  -  the  command 
center  for  an  IHAWK  fire  unit. 

COPY 

The  version  of  a  system  module  being  used 
to  simulate  an  individual  air  defense 
component . 

DB 

Data  Base  (MOPADS) 

DBAP 

Data  Base  Application  Program 

ENGAGEMENT  MARKERS 

A  mark  on  the  screen  of  a  Q-73  panel  to 
show  where  hostile  aircraft  are  being  engaged. 
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ENTITY 

Also  called  a  transaction,  a  simulation 
unit  vhich  flews  through  a  network  of 
task  nodes  and  branches. 

ESV 

Environmental  State  Vector 

FCO 

Firing  Console  Operator  -  the  operator  in 
the  IHAWK  system  responsible  for  obtaining 
a  radar  lock  on  a  hostile  aircraft  and 
pushing  the  fire  button. 

FIRE  UNIT 

A  ground  based  air  defense  unit  which 
has  fire  power  capable  of  destroying 
hostile  aircraft. 

HOOKED  ITEM 

At  a  Q-73  panel,  a  track  or  air  defense 
unit  nay  be  hooked.  Hooked  items  have 
a  special  section  of  alphanumeric  data 
describing  them.  Also  items  must  be 
hooked  in  order  to  send  communication 
messages  concerning  them. 

IA 

Information  Attribute  -  a  variable 
amongst  a  vector  of  values  (called  the  IA 
vector)  which  follow  an  entity  through  a 
simulation  network. 

IFF 

Identification  Friend  or  Foe. 

OSV 

Operator  State  Vector 

PAIRING  LINES 

Lines  on  a  Q-73  screen  representing 
which  fire  unit  is  assigned  to  which 
target  (hostile  aircraft). 

0-7  3 


Short  notation  for  the  AN/TSQ-73  missile 
minder. 


i 


i 
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RA 

Resource  Attribute  -  a  variable  amongst 
a  group  of  variables  which  follow  a 
resource  through  a  simulation  network. 

RU< 

Also  called  an  iteration.  A  complete 
simulation  from  start  time  through 
ending  time.  Statistics  are  summarized 
over  each  run.  Multiple  runs  can  be 
made. 

SA 

System  Attribute  -  a  variable  which  is 
"global"  to  a  given  copy.  Each  copy 
has  a  vector  of  SA  variables. 

SC 

Scaled  Constant  -  now  it  has  a  constant 
value  of  1.0. 

SCREEN 

ALPHANUMERICS 

A  Q-73  display  option  which  allows  the 
display  of  10  coded  characters  adjacent 
to  each  symbol  on  the  screen. 

SITE 

A  Q-73  unit  or  a  protected  area  (such  as 
an  airfield  or  command  center). 

SM 

System  Module  -  see  Air  Defense  System 
Module  in  the  MOPADS  terminology. 

TCA 

Tactical  Control  Assistant  -  IHAVK  oper¬ 
ator  responsible  for  IFF  procedures  aiid 
assisting  the  TCO. 

TCO 

Tactical  Control  Officer  -  Commanding 
Officer  of  an  IHAWK  BCC  unit. 

TO 

Tactical  Director  -  the  officer  in 
charge  of  a  Q-73  unit. 

* 


• 
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TDA 

Tactical  Director  Assistant  -  the 

Q-73  operator  who  assists  the  TD. 

TRACK. 

A  raw  video  mark  or  symbol  on  an  air 
defense  operator's  screen  which  repre¬ 
sents  the  location  of  an  aircraft. 

TTG  VECTOR 

A  line  emanating  from  a  track  on  the 

Q-73  screen  representing  the  location 
an  aircraft  will  be  at  in  a  given  time 
if  it  keeps  the  same  speed  and  heading. 

VELOCITY  VECTOR 

A  line  emanating  from  a  track  on  a 

Q-73  screen  representing  the  relative 
velocity  of  the  track. 
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I .  PURPOSE 


The  MOPADS  framework  requires  a  task  event  oriented  simulation 
languige  to  rim  MOPADS  simulations.  The  SAINT  simulation  language 
was  chosen  for  this  purpose  because  it  not  only  has  a  task  event 
orientation,  but  it  also  has  many  other  features  useful  to  MOPADS, 
such  frs  task  clearing  and  moderator  functions.  However,  several 
major  changes  and  additions  had  to  be  made  to  SAINT  to  render  it 
compatible  with  the  MOPADS  framework.  A  more  flexible  clearing 
methodology  was  implemented,  many  new  user-callable  utility  routines 
were  added,  and  a  new  method  of  allowing  multiple  air  defense  units 
to  be  simulated  using  only  one  network  (called  shareable  networks) 
was  implemented.  Several  SAINT  options  were  nullified  by  the  new 
design  constraints,  but  these  options  were  not  necessary  or  appro¬ 
priate  for  MOPADS..  The  new  version  of  SAINT,  enhanced  exclusively 
for  MOPADS,  is  now  called  MSAINT. 

^This  document  describes  the  changes  in  the  usage  of  SAINT. 
Instructions  and  definitions  for  al 1  additional  capabilities  are 
also  included.  It  is  assumed  that  the  reader  is  already  familiar 
with  the  material  in  Wortman,  Duket,  Seifert,  Hann  &  Chubb 
(1978a, b,c) . 

Section  II  of  this  document  shows  all  user  changes  by  section 
to  Wortman,  et  al  (1976a).  For  clarity  and  ease,  reference  Wortman 
et  al  ( 1978a)  will  be  shown  as  Reference  1  so  the  reader  may  -write 
the  changes  into  his/her  copy.  Section  III  describes  all  of  the 
additions  to  SAINT  implemented  in  MSAINT. 
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II.  CHANGES  TO  THE  SAINT  USER'S  MANUAL 


1- 0  INTRODUCTION 

Several  changes  have  been  made  in  the  usage  of  existing  fea¬ 
tures  in  SAINT.  Since  the  use  of  these  features  is  described  in 
reference  1,  this  section  vill  be  broken  down  into  subdivisions 
based  on  changes  to  individual  sections  in  reference  1.  This  sec¬ 
tion  is  somewhat  cryptic.  However,  Section  III  contains  more 
expansion  on  the  specific  modifications  for  MSAINT. 

2- 0  CHANGES  TO  SECTION  II  (REFERENCE  l) 

Page  13 


The  following  task  description  codes  can  no  longer  be 
used:  DMOD,  REGL,  SWIT. 

Page  lU-20 


Ignore  the  descriptions  of  the  usage  of  DMOD,  REGL, 
and  SUIT  cards.. 

Pages  27-28 

Task  Modification  is  no  longer  allowed. 

Pages  29-31 


Monitors  can  no  longer  be  used  because  appropriate  SS 
indices  cannot  be  predicted  at  run  time.  This  is  because  the  tracks 
only  temporarily  use  SS  variables.  The  MONF,  MTAS,  and  MSWT  designa¬ 
tors  can  no  longer  be  used.  il 

3-0  CHANGES  TO  SECTION  III  (REFERENCE  jjj 

Pages  33-33  -  Table  5  j 

[i 

The  following  cards  can  no  longer  be  used: 

SGE,  OUT,  UFL,  NMO,  DM0,  SWI,  REG, 

MON,  MTA,  MSW,  SST,  PLO,  VAR. 

The  SIM  and  FIN  cards  have  nev  definitions  shown  below: 

FIN  -  Signals  the  end  of  a  system  module 
data  input  deck 

SIM  -  Signals  the  end  of  all  decks,  thus  it 
is  the  last  card  in  he  deck  file. 
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Page  37 


Change  9*a  and  b  to  the  following  and  delete  9-c. 

a.  GEN,  POP,  and  DIS  cards  must  be  input  before 
any  other  card  type. 

b.  FIN  cards  follow  each  system  module  deck. 

A  SIM  card  signifies  the  end  of  the  data 
input  decks. 


Page  39 

Replace  with  Figure  II-l. 
Page  kO 

Disiegard  this  page. 

Page  Ul 

Replace  with  Figure  II-2. 
Pages  k2-h3 

Disregard  these  two  pages. 


GEN  - 

General 

System  Module 

Information 

Field 

Value 

Default 

Description 

1 

A 

■  — 

Card  Identification  (GEN) 

2 

A 

SAINT 

System  Module  Author  Name 
(max. of  8  characters) 

3 

I 

1 

Month  of  SM  Completion 

4 

I 

1 

Day  of  SM  Completion 

5 

I 

2001 

Year  of  SM  Completion 

6 

I 

0 

System  Module  Type 

=1  Control 
=2  Group  Q-73 
=3  Battalion  Q-73 
=4  IHAWK 

Figure  Il-i.  New  GEN  Card  Description. 
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POP  -  Program  Options  for  This  System  Module 


Field 

Value 

Default 

Description 

1 

A 

— 

Card  Identification  (POP) 

2 

I 

0 

Largest  resource  number  in 
.  this  SM 

3 

I 

0 

Number  of  RA's  per  resource 
in  this  SM 

4 

I 

2 

Number  of  IA's  per  informa¬ 
tion  packet  in  this  SM 

5 

I 

0 

Number  of  SA's  in  this  SM 

6 

I 

1 

Maximum  moderator  function 
number  used  by  this  SM 

Figure  II-2.  New  POP  Card  Description. 


Page  UU 

Note  that  distribution  sets  are  renumbered  starting 
with  1  for  each  system  module.  These  distribution  sets  are  used 
only  for  tasks  which  do  not  have  a  task  time  and  weighted  skill 
list  in  the  MOPADS  DB. 

Pages  47-^9 

User  observation,  time  persistent,  and  histogram 
statistics  are  all  cleared  at  the  beginning  of  each  run.  Therefore, 
they  are  only  used  for  statistics  collected  and  reported  at  the 
end  of  each  run.  User  statistics  of  each  type  are  renumbered 
starting  with  1  for  each  system  module. 

Pages  30-53 

It  is  strongly  suggested  that  UPL  and  VAR  cards  not  be 
used.  The  meaning  of  any  plots  would  be  hard  to  determine  because 
each  SS  variable  is  used  for  an  x,  y,  or  7.  coordinate  value  of  a 
track  only  for  the  time  the  track  is  in  the  system.  When  a  track 
leaves  the  system,  its  SS  variables  are  freed  up  to  possibly  be 
used  by  tracks  that  arrive  to  the  system  later. 

Page  5U 

Moderator  functions  are  not  renumbered  for  each  system 
module.  However,  each  copy  may  have  its  own  active  or  inactive 
status  for  each  moderator  function.  The  IMO  card  can  be  used  to 
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set  the  initial  status  of  each  moderator  function  in  each  copy  of 
the  current  system  module  to  the  same  value. 

Page  55 

This  card  can  be  used  to  set  all  initial  resource  attri¬ 
bute  values  in  each  copy  of  the  current  system  module  to  the  same 
initial  value.  If  certain  copies  have  unique  initial  values,  use 
subroutine  GRESA  to  initialize  these  values  (Polito  (1983a)). 

Note  that  UF  designations  in  field  U  and  subsequent  function 
fields  on  this  card  result  in  calls  to  function  USERIN,  not  USERF. 
See  Section  III,  3-0  for  a  description  of  the  usage  of  USERIN. 

If  the  SC  function  is  specified,  the  scaled  constant  is 
always  1. 

Page  56 

Usage  of  the  ISA  card  is  similar  to  that  for  the  IRA 
card.  The  ISA  card  will  initialize  all  specified  initial  system 
attribute  variables  in  all  copies  of  the  current  system  module  to 
the  same  value.  If  certain  copies  have  unique  initial  system 
attribute  values,  these  are  initialized  using  the  DBAP  routine  GSYSA 
(Polito  (1983a)). 

Like  the  IRA  card,  the  UF  designations  on  the  ISA  card  1 asult 
in  calls  to  function  USERIN,  not  USERF.  See  section  III,  3-0  for 
a  discussion  on  the  usage  of  function  USERIN. 

If  the  SC  function  is  used,  the  scaled  constant  is  always  1. 

Page  58 

Disregard  this  page. 

Pages  60-6l 

If  field  6  is  SC,  then  the  scaled  constant  used  is 
always  1.  Also  note  that  a  newer  TAS  card  description  is  given  in 
Wortman  &  O'Reilly  (1982). 

Page  6b 


Moderator  functions  themselves  are  not  unique  to  each 
copy.  However,  each  moderator  function  has  a  current  status  of  active 
or  inactive  for  each  copy.  It  is  suggested  that  all  moderators  be 
kept  inactive  and  then  activated  only  for  a  specific  task  node. 
Therefore,  fieids  U  and  5  (and  subsequent  status  and  duration  fields) 
would  normally  be  A  and  T  respectively. 
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A  newer  condition  code  list  for  conditional  branching  is 
given  in  Wortman  &  O'Reilly  (1982). 

Pages  72-73 

Disregard  these  two  pages. 

Pages  76-85 

Disregard  these  pages. 

Pages  87-90 

No  updated  version  of  Table  6  will  be  provided. 

U-0  CHANGES  TO  SECTION  IV  (REFERENCE  l) 

Page  92 

1.  Subroutine  INTLC  is  not  used  because  the  analyst 
cannot  initialize  SS  variables.  SS  variables  are  used  for  tracks 
and  are  set  internally  from  input  in  the  air  scenario. 

2.  The  variable  PFIRB  is  no  longer  used. 

3.  Function  PRIOR  is  no  longer  used. 

U.  Subroutine  STATE  has  already  been  written  and 
it  is  included  in  the  control  system  module. 

Page  93 

1.  Subroutine  UERR  is  called  when  a  fatal  error 
occurs  to  give  the  analyst  a  chance  to  print  out  special  information. 
The  fatal  error  code  value  is  passed  into  DERR  as  a  parameter. 

Various  ranges  of  error  codes  have  been  assigned,  and  these  are 
given  in  Figure  II-3.  Also  shown  is  a  flowchart  showing  UERR  calls 
to  handle  errors  by  system  module. 

2.  Function  USERF  is  called  only  for  UF  designators 
on  TAS  cards  and  ATA  cards.  It  is  used  only  to  set  task  times  or 
attribute  values.  General  user  code  should  be  callea  through  sub¬ 
routine  UTASK. 
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Figure  II- 
V 


3000-4999 

5000-5499 

5500-5749 

5750-5999 

6000-6999 

7000-7999 

8000-8999 


.  UERR  Flowchart  and  Error 


MSAINT  error 

Either  Group  or  Battalion 
Q-73  error 
Group  only  error 
Battalion  only  error 
IHAWK  error 

Common  System  Module  Programs 
Control  error 


Codes. 
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5-0  CHANGES  TO  SECTION  V  (REFERENCE  1) 


Pages  95-9^ 

These  routines  can  only  be  called  to  get ' information  on 
the  current  entity  at  the  current  task. 

Page  97 

Do  not  use:  GETPR,  PUTPR,  QRANK  or  TIMEQ. 


Pages  99-101 

Subroutines:  CLRHI,  CLROB ,  CLRTP,  UCLCT,  UHIST, 

IfTMSA,  and  UTMST 

have  been  revritten.  They  are  now  used  to  clear  or  collect  sta¬ 
tistics  only  and  not  to  print  out  any  statistics.  See  Figure  II-4 
for  descriptions  of  hov  to  use  these  routines. 

Page  102 

None  of  these  routines  are  available  now. 

6- 0  CHANGES  TO  SECTION  VII  (REFERENCE  l) 

Several  additional  error  codes  have  been  added.  These  are 
defined  in  Table  II-l.  This  table  could  be  considered  an  extension 
of  Table  lU  in  reference  1. 

7- 0  CHANGES  TO  SECTIONS  VIII,  IX,  AND  X  (REFERENCE  l) 

Page  119 

See  reference  6  for  a  description  of  the  implementation 
of  M0PADS  and  MSAII7T . 

Pages  120-121 

Disregard  these  tvo  pages.  MSAINT  and  MOPADS  are  now 
set  up  to  be  run  in  a  virtual  environment;  therefore,  no  overlay 
structure  is  used. 

Pages  122-126 


See  Section  III,  2-5  for  a  description  of  the  handling 
of  additional  dimensioning  requirements. 

Page  127 

See  Figure  III-U  for  a  new  MSAINT  common  listing. 

See  Figure  II-5  for  a  listing  of  subroutine  MAIN  (excluding  the 
common  blocks). 
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SUBROUTINE  CLRHI < IND, NCPT) 


C 

C*****CLEARS  THE  STORAGE  CELLS  FOR  EITHER  ONE  HISTOGRAM 
C«***»FOR  ONE  COPT  OR  ALL  HISTOGRAMS  FOR  ALL  COPIES. 
C*«***THIS  IS  FOR  USER  HISTOGRAMS. 

C 

C****#1NPUT  PARAMETERS* 

C  IND  *  >0  HISTOGRAM  NUMBER  TO  BE  CLEARED 
C  <0  CLEAR  ALL  USER  HISTOGRAMS 

C  NCPT  -  COPY  NUMBER  FOR  HISTOGRAM  TO  BE  CLEARED 
C  (NOT  USED  IF  IND<0> 

C 


SUBROUTINE  CLROBUND.NCPY) 

C 

C*««MCLEARS  THE  STORAGE  CELLS  FOR  EITHER  ONE  OBSERVATION 
C***«*STATISTIC  FOR  ONE  COPT  OR  ALL  OBSERVATION  STATISTICS 
C«****F0R  ALL  COPIES.  THIS  IS  FOR  USER  OBSERVATION  STATS. 
C 

C*****INPUT  PARAMETERS: 

C  INO  -  >0  USER  OBSERVATION  STAT  NUMBER  TO  BE  CLEARED 
C  <0  CLEAR  ALL  USER  OBSERVATION  STATS 

C  NCPT  -  COPT  NUMBER  OF  THE  COPT  WHOSE  OBSERVATION 
C  STATISTIC  IS  TO  BE  CLEARED  (NOT  USED  IF 

C  INDCO) 

C 


SUBROUTINE  CLRTP(IND,NCPY) 

C 

C*****CLE^RS  THE  STORAGE  CELLS  FOR  USER  TIHE-PERSISTENT 
C****«STATISTIC3  FOR  EITHER  ONE  TP  STAT  FOR  ONE  COPY 
C*****OR  ALL  TP  STATS  FOR  ALL  COPIES. 

C 

C****»lNPUT  PARAMETERS: 

C  IND  -  >0  TIME-PERSISTENT  STAT  70  BE  CLEARED 
C  <0  CLEAR  ALL  USER  TIHE-PERSISTENT  STATS 

C  NCPT  -  COPY  NUMBER  OF  STAT  TO  BE  CLEARED 
C  (NOT  USED  IF  INDCO) 

C 


Figure  II-U 


Usage  of  Statistics  Collection  Utilities 


SUBROUTINE  UCLCTUX, ICLCT, NCPY) 

C 

C*****THIS  SUBROUTINE  HUU  ONLY  COLLECTS  USER  OBSERVATION  STATS 
C 

C**»**INPUT  PARAMETERS: 

C  XX  -  VALUE  TO  BE  RECORDED  AS  AN  OBSERVATION 
C  ICLCT  -  USER  OBSERVATION  STATISTIC  NUMBER 
C  NCPY  -  COPY  ROU  NUMBER 
C 


SUBROUTINE  UHIST(XX,IHIST,NCPY) 

C 

C**m*NQU  USED  ONLY  FOR  COLLECTION 
C 

C***MINPUT  PARAMETERS: 

C  XX  -  OBSERVATION  VALUE  TO  BE  PLACED  IN  A  CELL 
C  ICLCT  -  USER  HISTOGRAM  NUMBER 

C  NCPY  -  COPY  NUMBER 

C 


SUBROUTINE  UTMSA(XX,T, ISTAT, NCPY) 

C 

C*****NO*J  USED  ONLY  TO  COLLEC’.  USER  AVERAGED  TINE-PERSISTENT 
C»****r  fISTICS.  SEE  THE  SAINT  USER'S  GUIDE ( JUNE  1978)  FOR 
C****-a  DESCRIPTION  OF  XX, T, AND  ISTAT.  NCPY  IS  THE  CURRENT 
C*****COPY  NUMBER. 

C 


SUBROUTINE  UTMST (XX ,T , ISTAT ,NCPT ) 

C 

C***#*NOU  USED  ONLY  FOR  COLLECTION 

C*****XX,T,  AND  ISTAT  ARE  DESCRIBED  IN  THE  SAINT  USEK  P 
C*****GUIDE  (JUNE  1978).  NCPY  IS  THE  COPY  NUMBER  FOR  THE 
C**»**STATISTIC  TO  BE  COLLECTED. 

C 


Figure  II— 1+  (continued) 


Table  II-l.  Additional  Execution  Error  Code  Definitions 


ERROR 

CODE 

ERROR  CONDITION 

LOCATION  OF 
CALL  TO  SSRR 

3607 

Zero  copy  number  passed  into 
BRAND.  Check  user  calls  to 

BRAND. 

BRAND 

1*002 

A  user  task  clearing  could  not 
be  performed  as  requested. 

Check  calls  to  UTCLR. 

CLRFl* 

1*003 

A  user  resource  clearing  could 
not  be  performed  as  requested. 
Check  calls  to  URCLR. 

CLRFl*  . 

l:00l* 

Overflow  of  JSIG  array.  Too 
many  user  task  and  resource 
clearings  and  signalings  at 
the  same  time.  Increase  the 
dimension  of  the  JSIG  array. 

URCLR 

UTCLR 

1*005 

Exactly  one  Task  must  be 
signaled  with  these  programs 

URCLR 

UTCLR 

1*010 

A  non-source  task  was  returned 
from  subroutine  GSOURA 

GASP 

loll 

1 _ 

Too  many  Control  Entities 

GASP 
( others ) 
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Figure  II-5.  Subroutine  MAIN 
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Page  129 

Add  the  rovs  contained  in  Table  11-2  to  Table  17  in 

reference  1. 

Pages  130-133 

No  revised  version  of  this  table  is  provided. 


Table  II-2.  Additional  MSAINT  Common  Block  Characteristics 


COMMON  BLOCK 

•  CHARACTERISTICS 

COM2  5 

User  Clearings 

C0M26 

MSAINT  Variables  Used  During 
Execution 

C0M27 

MSAINT  Variables  Used  During 

Input 

C0M28 

Current  Copy,  System  Module 
Number 

COM2  9 

Character  Variables 

> 


1 
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III.  ADDITIONS  TO  SAINT 


1- 0  INTRODUCTION 

Several  features  and  capabilities  have  been  added  to  SAINT  in 
the  implementation  of  MSAINT.  The  usage  of  these  new  capabilities 
is  described  in  this  section. 

2- 0  SHAREABLE  NETWORKS 

2-1.  General  Discussion 

■ .  . . .  I 

In  the  original  SAINT,  a ! simulation  could  be  run  only 
with  one  deck  of  data  cards  which  represents  one  system.  Each  j 
such  deck  of  data  cai*ds  could  then  hive  a  file  of  FORTRAN  subprograms 
which  are  called  during  the  simulation.  These  subprograms  are  hence¬ 
forth  referred  to  as  user  code.  Reference  1  describes  the  way  this 
user  code  was  interfaced  with  the  SAINT  software.  j 

j 

The  MOPADS  framework  requires  a  much  more  flexible  system  of 
inputting  and  using  SAINT  data  card  decks  and  their  associated  user 
code.  Generic  system  models  are  developed  for  each  type  of  air 
defense  component ,  such  as  an  AN/TSQ-73  missile  minder  or  an  IHAWK 
fire  unit.  Each  generic  model  contains  a  deck  of  MSAINT  data  cards 
and  a  file  of  user  code.  This  generic  model  is  called  a  system 
module.  Each  MOPADS  simulation  requires  only  one  system  module  input 
for  each  type  of  air  defense  component  in  the  simulation.  In  this 
way,  multiple  air  defense  components  6f  the  same  type  can  be  modeled 
using  only  one  set  of  data  input.  This  capability  is  called  share¬ 
able  networks,  since  each  of  the  like  components  are  sharing  the 
same  network  data  input.  ! 

If  five  AN/T3Q-73  units  are  simulated,  they  would  all  use  the 
same  system  module  input.  Each  of  the  five  units  would  be  celled  a 
"copy"  of  the  AN/TSQ-73  system  module.  Since  a  different  trace  of 
events  will  occur  for  each  copy  during  a  MOPADS  simulation,  MSAINT 
was  modified  to  keep  track  of  certain  data  on  a  copy  specific  basis. 
Statistics  are  collected  for  each  copy. 

i 

Since  each  MOPADS  simulation  will  most  likely  have  more  than 
one  type  of  air  defense  component,  multiple  system  modules  must  be 
included  in  the  data  input.  To  input  the  multiple  decks  of  data, 
the  decks  are  stacked.  A  new  data  card  type  was  added  (called  the 
SYS  card) .  This  card  is  placed  at  the  beginning  of  each  system  ■ 
module  input  deck.  See  Figure  III-l  for  a  pictorial  representation 
of  the  inputs  to  MSAINT. 
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One  system  module  consists  of  the  following: 


SYS,... 

SUBROUTINE... 

GEN,... 

POP,... 

DIS,... 

END 

• 

• 

• 

SUBROUTINE... 

• 

TAS,5,... 

• 

• 

DET,5,6* 

• 

END 

• 

FIN* 

ni 

DECK  OF  FILE  OF  FORTRAN 

DATA  CARDS  USER  CODE 


If  a  MOPADS  simulation  required  the  input  for  3  system 
modules,  the  data  card  decks  would  be  stacked  and  all  user 
code  would  be  linked  to  the  MSAINT  program. 

i 
I 
I 

SMI  | 

i 

I 

SM2  | 

I 
I 


SM  3 


I 


Stacked  decks 
of  data  input 


Figure  III-l.  Inputs  to  MSAIKT. 
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2-2.  SYS  Card. 


Each  system  module  input  deck  must  have  a  SYS  card  as 
its  first  card  and  a  GEN  card  as  the  second  card.  The  SYS  card 
is  automatically  created  by  the  MOPADS  software  and  placed  at  the 
top  of  each  deck  when  the  decks  are  stacked  (to  be  read  in  by 
KSAIHT).  Its  format  is  described  in  Figure  III-2. 

2-3.  Standard  Attribute  Values. 

Each  entity  which  flows  through  the  MSAIE?  networks 
must  have  at  least  two  Information  Attributes  (lA's).  The  meaning 
of  the  first  two  IA's  is  fixed.  The  first  IA  value  is  the  entity 
ID.  Entities  are  either  operators  or  control  entities  (non-opera¬ 
tors).  If  the  entity  is  an  operator,  its  ID  is  a  positive  integer. 
Control  entities  have  negative  ID's.  Operator  ID's  are  assigned  by 
the  MOPADS  software.  Some  control  entities  are  needed  to  nandle 
air  scenario  processing.  These  are  all  assigned  an  entity  ID  =  -1. 
All  other  control  entity  ID's  are  internally  assigned  in  the  order 
that  they  are  first  scheduled  at  a  source  node. 

The  second  standard  1A  value  is  reserved  for  the  copy  number 
of  the  copy  "owning”  the  entity.  Copy  numbers  (also  called  copy 
row  numbers)  represent  the  row  number  in  the  I1C0PY  array  and  other 
copy-specific  arrays  containing  data  on  the  copy.  Copy  numbers  are 
also  assigned  internally  when  the  entities  are  scheduled  at  source 
nodes. 


SYS 

-  System  Module 

Header  Card 

Field 

Value 

Default 

Description 

1 

Alphanumeric 

★ 

Card  Identification  (SYS) 

2 

Integer 

★ 

System  Module  Number 

1-  Control  System  Module 

2-  Q-73  Group 

3-  Q-73  Battal ion 

4-  IHAWK 

3  Alphanumeric  N  Echo  Gption 

N-  No  echo  provided 
P-  Partial  echo 
(Data  cards  only) 

F-  Full  echo 

(Data  cards  plus  formal 
echo  report) 

4  Integer  1  Number  of  copies  of  tn's  SM 

needed  for  the  current 
simulation. 

★ 

No  default  allowed,  this  field  must  be  specified. _ 

Figure  III-2.  SYS  Data  Card  Description 
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2-U.  TIev  Random  Number  Scheme 


Pseudo-random  numbers  are  used  by  MSAINT  to  sample  pro¬ 
babilistic  branching  and  for  the  generation  of  random  deviates  for 
task  times.  Formerly  in  SAINT,  one  pseudo-random  number  stream  was 
input  (or  the  default  vas  used)  and  all  uses  of  random  numbers  used 
the  same  stream. 

In  MSAINT,  one  seed  value  can  be  input  through  the  MOPADS  user 
interface.  From  this  seed  value,  random  samples  are  taken  to  produce 
initial  seed  values  for  each  copy  in  the  simulation.  During  the 
simulation  each  copy  will  then  sample  from  its  own  stream  of  pseudo¬ 
random  numbers.  Within  each  copy,  the  seme  stream  is  used  for  both 
probabilistic  branching  and  random  deviate  generation. 

A  new  FUNCTION  LRAND  was  implemented  in  MSAINT.  See  Figure 
III-3  for  a  listing  of  the  new  FUNCTION  DRAND. 

2-5*  Copy  and  System  Module  Specific  Arrays. 

A  dimension  vas  added  to  several  arrays  in  MSAINT  to 
account  for  storage  on  a  system  module  specific  or  copy  specific 
basis.  The  system  module  specific  arrays  need  to  keep  track  of  data 
only  for  each  system  module  type,  since  the  values  do  not  change 
between  copies  of  the  same  system  module.  The  copy  specific  arrays 
need  to  keep  track  of  data  which  is  unique  to  each  copy,  regardless 
of  the  system  module  type. 

During  the  usage  of  MOPADS  and  MSAINT,  it  may  become  necessary 
to  increase  the  number  of  system  modules  allowed  or  the  number  of 
copies  allowed  in  MSAINT.  This  would  involve  increasing  the  value  of 
one  or  both  of  the  following  variables : 

MMCPY  -  maximum  number  of  copies 

MMSY3  -  maximum  number  of  system  module  types 

Currently,  MMCPY  =  30  and  MMSYS  =  i*.  In  addition  to  increasing 
one  or  both  of  these  variable  values  ( set  in  the  MAINT  program  of 
MSAINT) ,  the  analyst  must  also  modify  the  dimensions  of  the  system 
module  specific  and/or  copy  specific  arrays  in  MSAINT  common.  A 
listing  of  MSAINT  common  is  shown  in  Figure  III-4. 

The  system  module  specific  arrays  are  listed  in  Table  III-l. 

The  copy  specific  arrays  are  listed  in  Table  III-2.  The  dimension 
number  refers  to  which  dimension  must  be  increased.  For  example, 
if  the  second  dimension  of  array  XX( 5,20,3),  was  to  be  increased 
to  30,  then  the  array  would  be  dimensioned  to  XX(5,30,3). 


FUNCTION  BRAND!  ISTRM) 


C****tALGORITHM  FOR  SEED  GENERATION  IS  ADAPTED  FROM  FUNCTION 
C****»RANb  DEVELOPED  BY  L.  SCHRAGE  AND  USED  UITH  THE  AUTHOR'S 
CJ**4* PERMISSION. 

C*»*»*DRAND  NOU  IS  PASSED  IN  THE  COPY  NUMBER  OF  THE  COPY 
C*****NEEDING  A  RANDOM  NUMBER.  EACH  COPY  HAS  ITS  OUN 
C**»**STREAM  NOU.  ALL  STREAMS  ARE  INITIALIZED  USING 
C«*«**THE  ONE  SEED  VALUE  PASSED  IN  FROM  THE  DATA  BASE. 

C****«A  DEFAULT  INITIAL  STREAM  IS  PROVIDED  IF  THE  USER 
C»»**«DOES  NOT  PROVIDE  ONE  THROUGH  THE  USER  INTERFACE. 

C 

C 

c: : 

COMMON  /C0M06/  TNOU  , TTNEX , MFAD . SEED , I  SEED  >  NCRDR  >  NPRNT  ,  NPUNCIi  , 

*  NRN I T , NRENT . MNDC  » NDC  >  NDTN  »  NNTC  > I  I SED I  3 1 > 

COMMON  /COM 24/  HHCPY . MMSYS . NTRACK I  3400 >  .  NAB  A21 150  )  >  MNAB2  >  NMCOP  <  4  >  . 

*  NXTTR.NTRID2I2.300) . NSSRW. MROUS . NCOLS . NXT I D . 

*  NSITEI  1100) .MNRU.MNCL iNCOPYI 30.24) . LFOP , LFDD . NXMON . 

*  NXUAY.NXYR.NFSTORl 750) , NFROU » NFCOLS » NFSPT , 

*  NEGIDI 150 ) ,  MMNEG i MCCOL . TSTRTK , TF I NK . BELT , HTRID > 

*  HSPTR.NNSTR.NCNEG.NDD4 ( 4. 2. 30) ,NTRDD( 3. 3) . 

*  NSCRNI 150,10) , NNDBA . NNDB4 , MOFR  >  HSCRN  >  MMTRD  > 

*  HDD  ADI  2 ,300)  ,  I1XDBD  ,  L  AST  M  ,  NMES  <  4  )  ,  NOPRI  (150,3) 
DIMENSION  XSTOR<750),XSITEl 1100) , XTRACK ( 3400 ) 

EOU I  VALENCE  I XSTPR ( 1 > , HFSTOR ( 1 ) > , ( XSI TE < 1 ) , NSITE < 1 ) ) , 

4  ( X  TRACK ( 1 ) , NT RACK ( 1 > ) 

DIMENSION  LSEEDI 31 ) 

DATA  L A. L bl 5, LB  1 6, LP/ 16807. 32768 ,05536 *21 4748364 7/ 

SAVE  LSEED 
IF(ISTRM)  20,10.70 
10  CALL  SERRI3607) 

20  ISTRG  =  -ISTRM 

IF< ISTRG-NNSTR)  30,30.10 
30  JSEED  =  1 1 SED I ISTRG ) 

GO  TO  60 

50  LSEEDI ISTRG)  =  JSEED  4  LP  4  1 
GO  TO  lOu 

60  IFI24I JSEED/2) .EQ. JSEED)  JSEED  »  JSEED  +  1 
IF  <  JSEED)  50,60.65 
45  LSEEDI ISTRG)  *  JSEED 
GO  TO  100 
70  ISTRG  -  ISTRM 

IF  I  I STRG-NNSTR )  80,80,10 
80  JSEED  =  LSEEDI ISTRG) 

LMI  -  JSEED/Lb 1 6 

LALO  =  I JSEED-LHI*LD16)»LA 

LEFTLO  *  LAL0/LD16 

LFHI  =  LHI *LAtLEFTLO 

K  =  LFHI /LB  1 5 

JSEED  =  I  I ILALO-LEFTLO*LB16)-LP)4(LFHI-K*LD15)*LB16 >4r 
IF! JSEED.LT .0) JSEED  ^  JSEED  4  LP 
LSEEDI ISTRG)  =  JSEED 

100  BRAND  =  FLOAT! JSEED ) *4 . 6566 1287SE- 1 0 
RETURN 
END 


Figure  III-3-  BRAND  Listing. 
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COMMON  /COMOl/  I  D  .  I  M .  I  MM » IMNA , IMN . MAXDS . NDNF T , MDNSS . 

*  ’  MDOAT  .MDQP.MDSTR.MEOT  >  MFLAG  >  r  ftp' TS  ,  HHDFN  >  HMSTU » 

*  MNCEL.MNCLS.  MHCLT  .MNCUP.MNHIsIhNOPA.MNPLT.  NNPTQ  > 

*  MNSTP  >  MNSUA  >  MNVAR  .MNVPP.MOPNCtMPARM.MPLOT.MSTAT.  ' 

*  MSYAT.MTCHR.MXSTA.MYABA.NOCI  j 

COMMON  /C0M02/  A  TR  I  B  (  3  )  .  J  TR  I  B  <  2  )  >  Cl  SE  T  (  3000  >  ,  NSET  (  4000  )  *  MFA . 

*  HXX.MrE<4>.MLE<4>,H<l<4) 

COMMON  /C0H03/  I POS . JP03 . KPOS . LPOS , MPOS , HP A . NAN . IESRU , IERRF , I F I N . 

*  IIECH.IN11XS.INHXT.IHBX.  JNBX.lfU'X'  IP .  NUMFL  .  ICONT  . 

*  HI  VAL .IBLNK.IZERO.LA.LB.LC.LD^LE.LF.LG.LH'LI. 

«  LJ.LK.LL.LM.LN.LO.LP.LQ.LR-LStLT.LU.LV.LW.LX.LY.LZ 

COMMON  /COMO A/  IPFAL ( 4 > . KRE AH < 45 ) . IFL AG ( 50 ) . I RSUL < 50 ) . RESUL <50 ) . 

*  IABCI8.30) .KARD<80) . IDIG(9>  1 

COMMON  /C0MO5/  NPRO J  <  A ) .MON<  4 > . NDA Y  <  4 ) ,NYR<4» , NAME < 2 . A ) . NRUN . 

*  NRUNS.NSKSR.NSKST  .NNEQD. NNECiSf. NNEQT 

COMMON  /C0M06/  TNOU . TTNEX . MFAB .SEED. I  SEED . NCRDR . NPRNT . NPUNCH . 

*  NRNIT i HRENT . MNDC » NDC . NBTN . NNTC . USED <31 > 

COMMON  /CQM07/  HUE  .  NOPAT  <  4  )  .  NSYAT  <  4  )  .  NDOP  (  A  >  !>  NMBFN  <  4  >  .  NN  <  4  )  . 

*  NPRMS  <  4 ) . JFLPR.NRNN,XINN,NFLAG.NNCLT(4> >NNHIS<4) . 

*  HNPLT,NNSTA.NNSTP(4) , HPLOT . NSTTS ( 4 ) 

COMMON  /C0M08/  HE  IP . NS  IF . ITR ACE . NRTSP . NRTEP  .  NTRACE .MTRACE . 

*  NSVVS.NSVVE.LTRACE.NRTSS.NRTES 

COMMON  /C0MO9/  P  AR  AM  <  1 00 . 3 . 4  )  ,  P  ARM  1  (  1  00 . 4  )  ,  PARM4  <  1  00  >  4  ) 

COMMON  /COM  1 0/  C AC  I N < 200 , 3 . 4 > , I T CHR ( 200 . 4  > . LL TSK < 200 . 2 . 4 > . 


COMMON  /COMIO/  CAC I N < 200 . 3 . 4 ) , I T CHR < 200 . 


.  TSK  ( 200 .2.4). 


LSINK(200»4).MACIN(200>4,4).MFEN(200.4)> 
HFSTT<200.4> .H0P<200.4> ,HP0<200.4> . NDCH ( 200 . 2 . 4 ) . 
NDEL <  200. 30 ) .NDPT  <200 .30) .HP0P(200.4 ) . NPOR<  200. 4 ) . 

*  NFSGN ( 200  *  4  > . NREL < 200 . 30 ) . NRELP < 200 . 4 ) . NREL2 < 200 . 4 ) 
»NSIGN<200,4> . NTC  <  200 . 30 ) . NTCHR < 200 . 4 ) . NT YPE < 200 . 4 ) 
.KM ARK <200. 4 ).XMARK<200.30) 

COMMON  /COM  11/  BUSY  (20. 30)  ,  LLRE  S  <  2  0 . 2 . 4  )  .  NBUS  <  20 . 30  ) .  NOPTR « 20 . 30  > . 
«  TLST (20,30) , NDPA  <  1800) . RS T AT < 80 , 30 ) . KFL AG < 20 . 30 > 

COMMON  /COP  1 2/  YABA(2550) »NAPA<750) »STCHR(2000) 

COMMON  /COrf  3/  MDFNS<20)  .MFSTl,  (20, 30)  .MFSTU<900) 

COMMON  /C0fft4/  NSINK(20.4),KSTPE(20,4),KSTTM(20»4) . XSTUS ( 20 » 30 > . 


COMMON  /C0M14/  NS  INK <20. 4) .KSTPE (20,4) »KSTTM(20,4) . XSTUS ( 20 , 30 > . 

*  !  NCELS!20.2, 30) , XLOLN  20. 4 > ,UIDTH(20, 4) , 

«  SUMA I (20,5.30) . SUM AF ( 20 , 3 , 30 ) . JCELS ( 3000 ) 

COMMON  /COM  15/  D£SCR<  10000)  ,  BOATT<  2000  )  ,  NDSTR  <  2400  )  »  SYSAT  (  30  >  30  > 
DIMENSION  NESCR ( 10000 ) 

EQUIVALENCE ( DESCR( 1 ) ,NESCR<  1  )  )  ! 

COMMON  /COM  16/  AAERR , B TH AX , B TM I N , PTSA V , 1 1 TES , LLERR . RRERR , TTL AS , 

*  TTSAV,DTSUC,DTFUL,L.TNOU,  ISEES.RESLS.DTACC.LLSAV, 

*  LSAVE 

COMMON  /COM  1 7/  SSdOOO  ),SSL<1000  > , DD < 1000 ) . DDL < 1 000 > 

COMMON  /COM  1 3/  IS(20) 

COMMON  /COM  1 9 /  LFL AG ( 20 ) . NPOSS ( 20 ) , NPOST ( 20 > . LLMON ( 20 . 2 > » 

*  NABAT ( 40 ) .NAB AS ( 60) , THRESt 120) 

DIMENSION  I THRS (120) 

EQUIVALENCE ( ITHRS  < 1 ) .THRESt 1)  ) 

COMMON  /C0M20/  NSTA  I  <  20  )'.  LLSVS  (  20 . 2  )  .  SSTPV  (  20 , 6  ) 

COMMON  /C0M21/  BTPLT< 10) . IITAP<10) ,NNPT5( 10) ,NMVAR( 10) iNNVPt 10) » 

*  LLPLT.NNPT .LLPHK 10) - LLPLOt 10) . LLSYM ( 10 > . PPHI ( 1 0 > , 

*  FPLCM  10) , NVPt 100) , LLSVP( 11 .2) .QPSET(llOO) 

COMMON  /C0M22/  TTIME.PFIRB 

COMMON  .'C0M23/  LLUGC  <  20 . 2 . 4  )  .  USOBV  (  20 , 5 . 30  >  ,  lLUGT  (  20 , 2  •  4  )  , 

*  TTCLR(20.30) ,USTPV(20.6»30) >  LLUGH ( 20 . 2 »  4 ) , 

*  t  NNCEL<20.2,30) , HHLDU < 20 » 4 > . HHU ID ( 20 . 4 > . J JCEL < 1500 > 
COMMON  /C0M24/  BPLOT  (  10 ) , I  TAPE ( 10) , NPTSV( 10 ) ,NVARS( 10) -LPLOT, 

*  NPTEX.LPHIHt 10) .LPLOU( 10) »LSYMB( 10 > .PHIHt 10) . 

*  PLOU( 10) ,LLUGP< 11 .2) , UPSET < 1100) 

COMMON  /C0M25/  JSIG(SOO) . M J S I G . NEX T SG 

COMMON  /C0M26/  MMCPY.MMSYS.NTRACK(3400).NABA2(150).MNAB2.NMC0P<4). 

*  NXTTR.NTRIP2(3.300) » HSSRU ,  .1R0US  .NCOLS  >  NXTI D , 

*  NSITEt  1100)  ,MNRU.MNCL»NC0PY(30,26)  .LFOP.LFDB.  NXMOH  . 

*  NXBAY.NXYR.NFSTOR ( 750) , MFROU , NFC0L5 > NFSPT , 

*  I  NEGID<150) iMMNEG, MCCOL.TSTRTN.T FINN, BELT, HTRID. 

t  I  NSPTR .NHSTR .NCNEG ,NDB4( 4 ,2. 30) ,NTRDB<3. 3) , 

*  I  ,  NSCRN! 150, 10) , NNBBA , NNDB4 , MOPR > MSCRN > MMTRD . 

«  NDBAD ( 2.300 >, MXDBB , LAS! M.NMES( 4 ) .NOPRI ( 150.3) 

DIMENSION  XSTDRt  750) .XSITE( 1100) .XTRACK (3400) 

EQUIVALENCE  ( XS TOR ( 1 ) . NFSTOR ( 1 ) ) . < XS I TE ( 1 ) . NSITE ( 1 ) ) . 

+  ( XTRACK ( t ) . NTRACK < 1  )  ) 

COMMON  /C0M27/  HCURS , NXDOAT . NCT < 20 . 4 ) , NCTU < 20 » 4 > . NCNEXT 

COMMON  /C0M28/  NCURCO . HCURSY , ISTATZ 

COMMON  /C0M29/  NTR1 D ( 300 ) , NXPRO J < 8 ) . NXNAME < 8 ) 

CHARACTER  NTR ID*8 , NXPRO J . NXNAME 


Figure  III-U.  Listing  of  MSAIWT  Common. 


Table  III-l.  System  Module  Specific  Arrays 


COMMON  BLOCK  ARRAY  NAME 


DIMENSION  NUMBER 


COM05 


COM07 


COM09 


COM10 


NPROJ 

1st 

MON 

1st 

NDAY 

1st 

NYR 

1st 

NAME 

2nd 

NOPAT 

1st 

NSYAT 

1st 

NDOP 

1st 

NMDFN 

1st 

NN 

1st 

NPRMS 

1st 

NNCLT 

1st 

NNHIS 

1st 

NNSTP 

1st 

NSTTS 

1st 

PARAM 

3rd 

PARM1 

2nd 

PARMU 

.  2nd 

CACIN 

3rd 

ITCHR 

2nd 

LLTSK 

3rd 

LSINK 

2nd 

MACIN 

3rd 

MFEN 

2nd 

MFSTT 

2nd 

MOP 

2nd 

NDCH 

3rd 

NPOP 

2nd 

NPOR 

2nd 

NPSGN 

2nd 

NRELP 

2nd 

NREL2 

2nd 

NSIGN 

2nd 

NTCHR 

2nd 

NTYPE 

2nd 

KMARK 

2nd 

COM11 


LLRES 


3rd 


Table  III-l  ( continued) 


COMMON  3I/5QC 

ARRAY  3AM? 

DECflJSlO  '  NUMBER 

CQMlU 

SS2SK 

2nd 

E3TPE 

2nd 

KSTCM 

2nd 

100’' 

2nd 

wnrj 

2nd 

COM2  3 

LI’j’GC 

3rd 

LLOCT 

3rd 

LLuca 

3rd 

HHLOW 

2nd 

HHWID 

2nd 

COM26 

NMCOP 

1st 

C0M27 

NCT 

2nd 

5CTU 

2nd 

Table  II1-2.  Copy  Specific  Arrays. 

COMMON  BLOCK 

ARRAY  SAKE 

DIMENSION  SUMS IS 

COM09 

NDEL 

2nd 

XDPT 

2nd 

HEEL 

2nd 

BTC 

2nd 

XMARK 

2nd 

CCM11 

3UST 

2nd 

SB  US 

2nd 

SCPTR 

2nd 

TLST 

2nd 

C0M13 

MFSTW 

2nd 

CCMll* 

XSTU3 

2nd 

3CZLS 

3rd 

CCKL5 

SYS  AT 

2nd 

COM2  3 

•JSCBV 

3rd 

usr ?r 

3rd 

2nd 

SNCZL 

3rd 

SCCPY 

1st 

XD3L 

2nd 

3-0  HEW  USER-WRITTEN  ROUTINES 


In  Section  IV  of  Reference  1,  several  user-written  routines 
are  described.  Also,  in  Section  II,  h-0  of  this  document  seme 
changes  in  the  usage  of  these  user-written  routines  ere  described. 

In  addition  to  these  changes,  three  new  user-written  routines  have 
been  added  to  MSAINT. 

SUBROUTINE  UTASK( NT. NPLACE) 

Subroutine  UTASK  is  called  once  each  time  a  task  node  reaches 
a  first  predecessor  completion  (FPC)  .release  time,  start  tia  com¬ 
pletion,  or  clearing.  Two  parameters  are  passed  into  subroutine 
UTASK,  the  task  node  number  (NT)  and  the  task  occurrence  time  (NPLACE). 
The  occurrence  times  use  the  following  codes: 

1  -  First  Predecessor  Completion  (FPC)-(if  different 

from  the  Release  time.  If  not,  then  UTASK 
is  not  called  with  NPLACE  «  1.) 

2  -  Release 

3  -  Start 

h  -  Completion 

5  -  Clearing 

Subroutine  UTASK  controls  the  task  driven  user  code  in  the 
system  module  user  code  files.  It  has  a  rigid  structure  which  is 
shown  in  the  form  of  a  hierarchy  chart  in  Figure  III-5.  UTASK  controls 
the  calling  of  subroutine  TRACE,  which  prints  trace  output  to  an 
external  file.  It  then  calls  a  special  controlling  routine  based 
on  the  current  system  module  (the  system  module  type  for  the  current 
entity  being  processed).  These  routines  then  call  individual  sub¬ 
routines  for  each  task  node  which  requires  unique  processing.  The 
parameter  NFLACE  is  passed  into  these  task  node  routines.  Each 
task  node  routine  may  then  have  a  computed  GO  TO  -statement  with 
NPLACE  as  the  parameter  (with  values  1  to  5).  In  this  way  code 
which  is  unique  to  the  task  occurrence  time  can  be  easily  reached. 

As  each  system  module  is  added  to  MOPADS,  one  controlling 
routine  must  be  added  to  be  called  by  UTASK,  The  individual  task 
routines  must  then  be  called  by  it  for  the  tasks  in  that  system 
module. 


WARNING 

Information  attributes  of  the  current  entity 
may  not  be  changed  at  node  release  time  (NPLACE=2). 
This”is  necessary  to  implement  self  clearing  (see 
Section  III,  4-3)„ 
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•JTASK 


One  subroutine  for  each  task  r.ode  in  the 
Q-73  Group  system  module.  (Likewise  for 
the  other  three  routines- 
UTCNLC,  UTBNQ,  and  UTHWKW.) 


Figure  III-5.  OTASK  Hierarchy  Chart 
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SUBROUTINE  USTART ( NRUN ) 


Subroutine  USTART  is  called  to  allow  the  analyst  to  initialize 
variables  and  arrays  at  the  beginning  of  each  run.  NRUN  is  passed 
in  as  the  run  number  of  the  run  about  to  be  made.  Separate  routines 
should  then  h-*  called  to  initialize  the  variables  and  arrays  by 
system  module. 

FUNCTION  USERIR(NCODE) 

The  MOPADS  analyst  can  use  IRA  and  ISA  cards  in  system  module 
data  ’nput  decks.  For  a  description  of  the  usage  of  IRA  and  ISA 
cards,  sea  reference  1.  These  cards  are  used  to  set  Initial  values  of 
resource  attributes  and  system  attributes.  The  same  initial  value 
is  then  used  for  the  attributes  in  each  copy  of  the  system  module. 

If  the  UF  designation  is  used  to  set  these  initial  attributes, 
then  function  USER  IN  will  be  called.  The  UF  code  vill  be  passed  in 
as  the  parameter  NCODE.  The  codes  for  calling  US  ERIN  and  US  ERF  are 
independent  of  each  other.  U3ERF  is  called  for  all  UF  designations 
on  all  card  types  other  than  IRA  and  ISA  cards. 

k~0  NEW  USER-CALLABLE  ROUTINES 

Several  nev  utility  routines  were  added  to  MSAINT  to  perform 
specialized  processing  from  system  module  user  code.  The  usage  of 
these  is  defined  in  this  section. 

U-l.  Cory  and  System  Module  Information. 

System  modules  are  numbered  1  through  U  currently.  The 
code  values  are  defined  below. 

Codes  for  System  Modules 

1  -  Control  (track  processing,  simulation  time) 

2  -  Group  Q-73 

3  -  Battalion  Q-73 

k  -  IRAWK 

Other  codes  will  be  added  as  system  modules  are  added  to 
MOP ATS. 

Copies  are  numbered  1  through  30  currently.  Copy  numbers  are 
assigned  when  the  copy  data  is  placed  in  the  NCOFY  array  from  the 
MOPADS  DB. 

In  addition  to  these  identifying  numbers,  each  copy  has  what 
is  called  a  copy  ID.  The  copy  ID  is  stored  in  column  1  of  the  NCOPY 
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array.  It  ia  a  1»- digit  number  ’mi quo  to  each  copy  which  is  assigned 
by  the  MOPADS  software.  There  ie  currently  no  reason  for  the 
analyst  to  use  the  copy  ID  because  the  copy  row  number  is  the  number 
used  to  uniquely  address  copies  in  user  code. 

The  utility  routine  descriptiout  aia  included  in 
Figure  III-6.  The  comment  sections  cf  each  routine  should  suffi¬ 
ciently  describe  their  *u«jge. 


SUBROUTINE  IDC3PY(NCIDf NNSYS.NMCOP) 

C 

C****«BREAKS  B3UN  THE  4  916X7  COPY  ID  INTO  THE 
C*«*«*SrSTEn  NODULE  NUMBER  AND  THE  COPY  NUMBER 
C*****UITHIN  THAT  SYSTEM  MODULE. 

C 

C*****INPUT  PARAMETERS  I 
C  NCII  -  COPT  ID 

C 

C»#*»*0UTPUT  PARAMETERS* 

C  NNSYS  -  SYSTEM  MODULE  NUMBER 

C  NNCOP  -  COPT  NUMBER 

C 


SUBROUTINE  FIN9C(N2SYS(NDIM,ITEMP,!NUM) 

C 

C*****FINDS  ALL  COPY  ROU  NUMBERS  FOR  A  GIVEN  SYSTEM 
C*****H0DULE  NUMBER 
C 

c«*«mjnput  parameters* 

C  N2SYS  -  SYSTEM  MODULE  NUMBER 
C  NDIM  -  IIHENSIQN  OF  ITEMP 

C  i 

C«t***0UTPUT  PAR.METERSi 

C  ITEMP  -  ARRAY  CONTAINING  THE  COPY  ROU  NUMBERS 
C  I HUM  -  -2  ILLE6AL  SYSTEM  MODULE  NUMBER 
C  -I  TOO  MANY  COPY  ROU  NUMBERS  FOR  ITEMP 

;  >»0  NUMBER  OF  COPT  ROU  NUMBERS  IN  ITEMP 

C 


Figure  III-6.  Descriptions  of  Utilities  Providing  Copy  and 
System  Module  Information. 
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SUBROUTINE  GTCOPYt I ROU, NF,NL,IDIM, ISTORE) 

C 

C*«»**USED  BY  VARIOUS  UTILITIES  TO  GET  INFORMATION 
OUT  OF  THE  NCOPY  ARRAY,  GIVEN  THE  COPY  ROU  M. 

C 

C*****INPUT  PARAMETERS! 

C  IROU  -  COPY  ROU  I 
C  NF  -  FIRST  COLUMN  OF  INFORMATION 
C  NL  -  LAST  COLUMN  OF  INFORMATION  <  SAME  AS  NF  IF 
C  ONLY  ONE  UORD  UANTED) 

C  IDIH  -  DIMENSION  OF  ISTORE  (NUMBER  OF  UQRDS  UANTED) 
C 

C*****OUTPUT  PARAMETERS: 

C  ISTORE  -  ARRAY  CONTAINING  THE  DESIRED  VALUES  FROM 
C  THE  NCOPY  ARRAY 

C 


FUNCTION  NCOP(ICN) 

C 

C*«***6I VEN  THE  COPY  ROU  HUMBER,  RETURNS  THE  4  DIGIT 
C»««**COPY  ID  FROM  THE  NCOPY  ARRAY. 

C 

C***««INPUT  PARAMETERS! 

C  ICN  -  COPY  ROU  • 

C 

C****»OUTPUT  PARAMETERS! 

C  NCOP  -  COPY  ID 

C 


FUNCTION  NCOPR(IOPR.KFLG) 

C 

C*****RETURNS  THE  COPY  ROU  NUMBER  FOR  A  GIVEN  ENTITY  ID 
C*****ALSO  SETS  THE  CURRENT  COPY  AND  SYSTEM  MODULE  IF 
C*****KFL6  *  t. 

C 

C*****INPUT  PARAMETERS! 

C  IOPR  -  ENTITY  ID  (<0  NON-OPERATOR,  >0  OPERATOR) 

C  KFLG  -  FLAG  TO  INDICATE  IF  THE  CURRENT  COPY 
C  AND  SYSTEM  MODULE  ARE  TO  BE  SET 

C 

C»‘ ••♦OUTPUT  PARAMETERS! 

C  HC0PR  -  0  MEANS  THE  ID  HAS  NO  COPY  iD 
C  >0  COPY  ROU  NUMBER  CONTAINING  THE  ENTITY 

C  UITH  ID  IOPR 


Figure  III-6.  (continued) 
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FUNCTION  NSYS(ICN) 

C 

[♦♦•♦♦RETURNS  the  system  module  number  GIVEN  THE  COPY  RQ“  * 


<.”w  otanoran  rapnafcnm^ 


C 

[♦♦♦♦♦INPUT  PARAMETERS: 

C  ICN  -  COPY  ROU  NUMBER  (IN  THE  NCOPY  ARRAY! 
C 

[♦•♦•♦OUTPUT  PARAMETERS: 

C  NSYS  -  SYSTEM  MOBULE  NUMBER 
C 


Figure  III-6.  (continued) 


4-2.  Task,  Entity,  Resource,  and  Attribute  Data. 

Entities  flow  through  the  MSAUTT  networks  from  task  node 
to  task  node.  Task  nodes  sometimes  require  resources- to  perform  the 
tasks.  There  are  three  types  of  attributes:  1)  information, 

2)  resource,  and  3)  system.  See  Wortman  et  al  ( 1978b)  for  a  more 
detailed  description  of  these  items. 

Information  involving  these  simulation  items  can  be  obtained 
using  the  utility  routines  described  in  this  section.  See  Figure 
III- 7  for  these  description. 


* 


4-3.  User  Clearing. 

Formerly  In  SAUTT,  clearing  was  restricted  to  the 
following  procedure.  When  one  task  reaches  Its  completion  time,  if 
it  baB  a  TCL  or  RCL  designator  on  it,  it  would  cause  the  specified 
other  task  to  be  cleared  from  its  current  task  to  a  specified  task  to 
be  signaled.  This  procedure  turned  out  to  be  overly  restrictive  for 
usage  in  the  MOPADS  framework.  For  this  reason,  user  clearing  was 
implemented  in  MSAIMT.  User  clearing  allows  any  task  to  be  cleared 
by  any  other  task  in  the  same  copy  from  calls  to  UTCLR  or  URCLR  in 
user  code.  In  addition,  entities  can  clear  themselves  at  release 
times  from  their  current  task  node  by  calling  subroutine  SCLEAR. 

The  usage  of  these  three  utility  routines  is  described  in 
Figure  III-8. 
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FUNCTION  CTIME(NTASKf NOPR, IERR) 

C 

C*****RETURNS  T HE  SCHEDULED  TASK  COMPLETION  TD.E 
C***s*eOR  A  GIVEN  OPERATOR-TASK.  ASSUMES  THE  FIRST 
€***•»*  INFORM  AT  I  ON  ATTRIBUTE  IS  THE  OPERATOR  IU. 

C 

c*****input  PARAMETERS 
C  NT  ASK  -  TASK  NUMBER 

C  NOPR  -  OPERATOR  ID 

C 

C*M**OUTPUT  parameters 
C  IERR  -  1  IF  NO  ERRORS 
f  2  IF  TASK  : J'JMBER  ILLEGAL 

„  3  TASK  ;-Oi  ACTIVE  FOR  THE  BrVEF 


■"  4 


V 


0 


C  OPERATOR,  THEREFORE  NO  SCHEDULED 

C  TASK  COMPLETION  > 1ME 

C  CT1ME  -  SCHEDULED  TASK  COMPLETION  TIME 


SUBROUTINE  GETIAI <NAT,NVAL> 

C 

C»****UORKS  SAME  AS  THE  ROUTINE  GETIA  EXCEPT  IT  RETURNS 
C*****THE  VALUE  AS  AN  INTEGER 
C 

C***»«I||PUT  PARAMETERS: 

C  NAT  -  INFORMATION  ATTRIBUTE  NUMBER 


C 

C*****OUTPUT  PARAMETERS! 

C  NVAL  -  THE  CURRENT  VALUE  OF  INFORMATION  ATTRIBUTE  NAT  FOR 
C  THE  CURRENT  ENTITY 

C 


SUBROUTINE  GTIAV(LOPR, XIA,IADIH, IERR) 

C 

C*+***0BTAIN  THE  1A  VALUES  FOR  A  GIVEN  OPERATOR 
C 

C**#**INPUT  PARAMETER 

C  LOPR  -  OPERATOR  ID  NUMBER  (ASSUMED  TO  BE 
C  INFORMATION  ATTRIBUTE  1 

C  (IF  0  USE  CURRENT  ENTITT) 

C 

Figure  III-7-  Descriptions  of  Utilities  Providing  Task,  Entity 
Resource,  and  Attribute  Data. 
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C*****OUTPUT  PARAMETERS 

C  XIA  -  ARRAY  CONTAINING  THE  CURRENT  VALUES  OF 
C  THE  INFORMATION  ATTRIBUTE  VECTOR  FOR 

C  OPERATOR  LOPR  (MUST  BE  DIMENSIONED 

C  TO  IADIH  IN  THE  CALL1N6  SUBPROGRAM) 

C  IADIH  -  DIMENSION  OF  XIA 
C  IERR  -  «  -1  TOO  MANY  IA'S  FOR  ARRAY  XIA 
C  *C  OPERATOR/IA'S  HOT  FOUND 

C  >0  NUMBER  OF  IA'S  PUT  IN  XIA 

C 


SUBROUTINE  GTNUHfNTDIM, NFILE, NUMT,  I ERR) 

C 

C****#FINDS  THE  TASK  NUMBERS  FOR  ALL  TASKS  IN  EITHER 
C*«***THE  EVENT  FILE  OR  THE  UAIT-FOR  RESOURCES  FILf . 
C***MALSO  RETURNS  THE  COPY  NUMBER  FOR  EACH  TASK  FOUND. 

C 

c*«***imput  parameters 

C  NT91N  -  NUMBER  OF  ROUS  IN  NUMT 
C  (NUNT  ALWAYS  HAS  TUO  COLUMNS) 

C  HFILE  -  FILE  TO  SEARCH  FOR  TASKS 
C  *  t  SEARCH  THE  EVENT  FILE 

C  >2  SEARCH  THE  UAIT-FOR-RESOURCES  FILE 

C 

C**#**OUTPUT  PARAHETERSi 

C  NUMT  -  ARRAY  CONTAINING  THE  TASK  NUMBERS  AND 
C  COPY  NUMBERS  OF  ALL  TASKS  IN  FILE  NFILE. 

C  NUMT (1,1 )  IS  THE  TASK  NUMBER  OF  THE  I  TH 

C  TASK  FOUND  AND  NUHT(I,2>  IS  THE  COPY  ROU 

C  NUMBER  OF  THE  I  TH  TASK  IN  FILE  NFILE. 

C  IERR  -  *-2  IF  AN  ILLEGAL  NFILE  NUMBER  PASSED  IN 
C  »-1  IF  MORE  THAN  NTDIH  TASKS  FOUND 

C  *0  IF  NO  TASKS  FOUND  IN  FILE  NFILE 

C  >0  NUMBER  OF  TASKS  FOUND  AND  PLACED  IN  NUMT 

C 


SUBROUTINE  GTOPRTCIDENT,NTASN,IERR> 

c 

C*+***FOR  A  GIVEN  OPERATOR,  LOCATES  THE  TASK 
C*»**tUHERE  THE  OPERATOR  13  AT.  ASSUMES  THAT 
C***mEACH  OPERATOR  IS  AN  ENTITY  WITH  INFORMATION 
C*»*»*ATTRIBUTE  1  BEING  THE  ID. 

C 

C***mINPUT  PARAMETER: 

C  IDENT  -■  OPERATOR  IB  NUM8ER 
C 

figure  III-7*  (continued) 
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C*»***OUTPUT  PARAMETERS 

C  MTASN  -  TASK  NUMBER  UHERE  OPERATOR  IDENT 
C  NOU  I S < RETURNED  AS  NEGATIVE  IF  THE 

C  TASK  IS  WAITING  FOR  RESOURCES) 

C  IERR  -  1  IF  TASK  NUMBER  UAS  OBTAINED 
C  2  IF  NO  TASK  NUMBER  FOUND 

C 


SUBROUTINE  STSTATINRESS, ICPY .NSTTA,NTASK, IERR) 

C 

C*****RETURNS  THE  STATUS  OF  A  GIVEN  RESOURCE  FOR  THE  INDICATED  COPY 
C 

C*****INPUT.  PARAMETERS 
C  NRESS  »  RESOURCE  NUMBER 

C  ICPY  -  COPY  ROU  NUMBER 

C 

C*#***0UTPUT  PARAMETERS 
C  NSTTA  -  STATUS  OF  RESOURCE  NRESS 
C  «  1  IF  RESOURCE  SUSY 

C  «  0  IF  IDLE 

C  IERR  >  1  IF  RESOURCE  FOUND,  NO  ERRORS 
C  2  ILLEGAL  RESOURCE  NUMBER 

C  NTASK  -  TASK  NUMBER  UHERE  THE  RESOURCE  IS  BEING 
C  USED <  >0  IF  IDLE  OR  IERR  =  2) 

C 


SUBROUTINE  PUTIAI (NAT,NVAL) 

C 

C**a**UORKS  THE  SAME  AS  SUBROUTINE  PUTIA  fXCEPT  THAT 
C*****IT  PASSES  IN  THE  VALUE  AS  AN  INTEGER 
C 

C*a*a*INPUT  PARAMETERS: 

C  NAT  -  INFORMATION  ATTRIBUTE  NUMBER 
C 

Caa**«OUTPUT  PARAMETERS: 

C  NVAL  -  VALUE  TO  BE  PLACED  IN  INFORMATION  ATTRIBUTE  NAT 
C 


Figure  III-7-  (continued) 
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SUBROUTINE  URCLR ( 1RNUM, NSIG r NUMSG, ICPY , IERR) 

C 

C*****USER  CALLABLE  ROUTINE  TO  INITIATE  A  RESOURCE  CLEARING 
C*****FROM  USER  CODE.  AN  ENTRY  IS  PUT  INTO  FILE  4  TO  REPRESENT 
C****$A  CLEARING  EVENT.  THESE  ENTRIES  ARE  THEN  PULLED  OUT 
C*****AND  PROCESSED  BEFORE  THE  NEXT  TASK  COMPLETION. 

C 

0****INPUT  PARAMETERS: 

C  IRNUN  -  RESOURCE  NUMBER  TO  BE  CLEARED 
C  NSIG  -  ARRAY  CONTAINING  TASK  NUNBERS  TO  BE  SIGNALED 
C  NUMSG  -  NUMBER  OF  TASK  NUMBERS  IN  NSIG 
C  ICPY  -  COPY  ROU  NUMBER 
C 

C*****ouTPUT  PARAMETERS: 

C  IERR  -  0  NO  ERRORS 

C  1  RESOURCE  IRNUN  NOT  BUSY;  NO  CLEARING  DONE 

C  2  RESOURCE  NUMBER  IRNUM  IS  ILLEGAL 

C  3  AT  LEAST  ONE  OF  THE  TASK  NUMBERS  IN  NSIG 

C  IS  ILLEGAL 

C 


SUBROUTINE  UTCLR < NCLR , IOPR,NSIG, NUMSG, LOPT , IERR) 

C 

C*****USER  CALLABLE  ROUTINE  TO  INITIATE  A  TASK  CLEARING 
C** ***EVENT  FROM  USER  CODE.  AN  ENtrRY  IS. PUT  INTO  FILE  A  TO 
C*****REPRESENT  A  CLEARING  EVENT. 

C 

0****INPUT  PARAMETERS: 

C  NCLR  -  TASK  NUMBER  TO  BE  CLEARED 
C  IOPR  -  OPTION  FOR  SPECIFYING  JUST  AN  OPERATOR  ID. 

C  <0  CLEAR  ALL  INCIDENCES  OF  TASK  NCLR  FOR  THE 

C  CURRENT  COPY 

C  >0  CLEAR  ONLY  THE  INCIDENCE  OF  TASK  NCLR 

C  UITH  OPERATOR  IOPR  AT  IT 

C  NSIG  -  ARRAY  CONTAINING  ALL  TASK  NUMBERS  TO  BE 
C  SIGNALED 

C  NdrtSG  -  NUMBER  OF  TASK  NUMBERS  IN  NSIG 
C  LOPT  -  1  CLEAR  THE  TASK  ONLY  IF  ACTIVE 
C  2  CLEAR  THE  TASK  ONLY  IF  UAITING  FOR  RESOURCES 

C  3  CLEAR  THE  TASK  IF  EITHER  ACTIVE  OR  UAITING 

C  FOR  RESOURCES 

C 


Figure  III-8.  User  Clearing  Utility  Routine  Descriptions. 
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c**«**output  parameters* 

C  IERR  -  0  NO  ERRORS 
C  1  UNABLE  TO  CLEAR  THE  TASK 

C  2  TASK  NUKBER  NCLR  IS  ILLEGAL 

C  3  AT  LEAST  ONE  TASK  NUMBER  IN  NSIB  IS  ILLEGAL 

C 


SUBROUTINE  SCLEAR<NCURR,I0PR,NTASB,NT1ME,IERR> 

C 

C*****PERFORrtS  A  SELF  CLEARING  OPERATION.  THIS  IS  ACCOMPLISHED 
C**»**BY  CALLING  UTCLR  TO  PLACE  A  USER  CLEARING  EVENT  IN  FILE  A. 
C*****0NLY  ONE  TASK  CAN  BE  SIGNALEDTBRANCHED  TO).  THIS  ROUTINE 
C*****IS  SET  UP  TO  BE  CALLED  FROM  UTASK  ONLY  AT  RELEASE  TIMES. 

C 

U****1NPUT  parameters 

C  NCURR  -  CURRENT  TASK  NUMBER  TO  PE  CLEARED  I  < 

C  IOPR  -  CURRENT  OPERATOR  ID  T*0  EE  CLEARED 
C  NTASB  -  TASK  NUMBER  TO  BE  SIGNALED 

C  NTIME  -  PASSED  IN  FROM  UTASK.  USED  FOR  ERROR  CHECKING  TO 

C  ASSURE  SCLEAR  UAS  CALLED  AT  A  RELEASE  TIME 

C 

C*4***OUTPUT  parameters 

C  IERR  -  0  -  NO  ERRORS.  CLEARING  AND  SIGNALING  UAS  DONE 
C  1  -  NOT  CURRENTLY  A  RELEASE  TIME 

C  2  -  ENTITY  TO  BE  CLEARED  IS  ILLEGAL (  WRONG  TASK 

C  NO.  OR  OPERATOR  ID  SPECIFIED) 

C  3  -  TASK  NO.  TO  BE  SIGNALED  IS  ILLEGAL 

C  A  -  ERROR  IN  SETTING  UP  USER  CLEARING(TASK  TO 

C  BE  CLEARED  NOT  IN  WAIT  FILE)  t 

C 


Figure  III-8.  (continued) 
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If  -L,  General  Simulation-Related  Data. 


Tvo  generel  purpose  utilities  were  added  to  MSAIHT. 
Subroutine  GTTIM  retrieves  the  current  simulation  time  and  subroutine 
P^IT/K  prints  out  the  list  of  entities  and  their  first  five  IA  values 
for  all  entities  in  the  given  file.  File  1  is  the  event  file  and 
file  2  is  the  wait -for-re sour les  file.  See  Figure  III-9  ior  full 
descriptions  of  the  usage  of  uhese  routines. 


SUBROUTINE  GTTIM { TT > 

C 

C*****0BTAINS  THE  CURRENT  SIMULATION  TIME 
C 

C*****0UTPUT  PARAMETERS 

C  TT  -  CURRENT  SUMULATICN  TIME 

C 


SUBROUTINE  PFILE(NFIL) 

C 

C***#*PRINTS  out  the  contents  of  a  file,  it  does 
G*****THIS  BY  PRINTING  ONE  SOU  CF  INFORMATION  FOR  EACH  FILE 
C****#ENTRY.  EACH  ROU  CONTAINS  THE  ENTRY  NUMBER,  TASK 
C*****NUMBER  OF  THE  ENTRY,  AND  THE  FIRST  FIVE  INFORMATION 
C*****ATTRIBUTE  VALUES. 

C 

C*****INPUT  parameters 

C  NFIL  -  FILE  NUMBER  OF  THE  FILE  TO  BE  PRINTED  OUT 
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5-0  USER  ACCESSIBLE  DATA  STRUCTURE  DEFINITIONS 
5-1.  General  Discussion. 


Several  arrays  and  variables  have  been  added  to  MSAINT 
labeled  common  blocks  to  store  MOPADS  data  vhich  is  frequently 
accessed.  Some  of  these  variables  are  used  internally  by  MSAIHT; 
therefore,  their  meaning  and  usage  are  of  no  consecuence  to  the 
analyst.  However,  several  of  the  new  variables  contain  information 
that  may  be  accessed  by  system  module  user  code.  The  MOPADS 
analyst  needs  to  know  the  meaning  of  these  variables  and  how  to 
access  them.  This  information  is  provided  here. 

Several  arrays  have  been  set  15)  as  one-dimensional  arrays  in 
MSA1JTT  common,  but  they  are  treated  as  two-dimensional  arrays.  These 
arc  referred  to  as  pseudo-tvo- dimensional  arrays.  Each  two-dimen¬ 
sional  array  is  actually  stored  by  FORTRAN  as  one  long  stack  of 
columns,  see  Figure  III-10.  Sow  assume  that  you  have  a  one-dimen¬ 
sional  array  partitioned  into  sections.  Each  section  has  the  same 
number  of  elements,  and  the  last  word  of  each  section  is  a  pointer 
variable.  The  array  wo’ild  look  like  the  one  in  Figure  III-ll(a). 

Now  take  each  section  and  put  them  side  by  side  ar.d  refer  to  each 
section  as  a  "column"  (Bee  Figure  III-ll(b)).  All  of  the  pointer 
elements  now  line  up  to  be  the  last  row  of  the  columns .  Coltur* 
can  be  used  or  unused.  For  unused  columns,  the  pointer  elemen' 
points  to  the  next  unused  column.  All  used  columns  have  a  -1  In  the 
pointer  element.  A  separate  variable  points  into  the  array  to  the 
first  unused  column.  Hence,  a  one-dimensional  linked  list  system  is 
used  ;o  keep  track  of  the  unused  columns.  If  a  new  column  Is  needed, 
the  first  unused  column  (pointed  to  by  the  outside  variable)  is 
used  and  the  pointer  structure  is  updated.  The  pointer  structure 
Is  also  updated  when  a  column  is  freed  up.  Each  array  of  this  type 
then  has  a  fixed  number  of  columns  and  rows.  The  product  of  the 
number  of  columns  and  rows  must  of  course  be  equal  to  the  dimension 
of  the  array.  This  type  of  data  structure  provides  the  flexibility 
needed  to  keep  track  of  items  vhich  may  come  and  go  from  the  system. 
Also,  the  MOPADS  analyst  may  want  to  vary  the  number  of  columns  and 
rows  to  account  for  additional  data. 

Track,  site,  and  fire  unit  data  are  stored  in  pseudo-two-dimen- 
sior.al  arrays  in  MSAINT  labeled  common.  Some  additional  information, 
auch  as  alphanumeric  labels  for  the  track  sites,  and  fire  units,  is 
also  stored  in  that  type  of  array.  In  Section  5-2  these  arrays  are 
defined. 

Several  utility  routines  have  been  included  in  the  MOPADS 
software  for  handling  these  arrays:  SETVTJ,  PTELU,  GTELU,  GTRWIJ, 

PTRWJ.  These  routines  are  described  in  Polito  &  Goodin  (1983). 

A  li3t  of  MSAIHT  common  can  be  seen  in  Figure  III— U . 


I 
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The  nunbers  down  the  left  hand 
side  represent  the  sequential 
order  of  elements  of  ITWO  as 
they  are  stored.  The  numbers 
down  the  right  hand  side  rep¬ 
resent  the  array  elements  and 
their  position  ir,  the  "stack." 


Figure  III-10.  ABRAY  1TWO  (u.k)  As  Stored  By  FORTRAN. 
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SECTION  1 


SECTION  2 


SECTION  3 


ARRAY  I TWO 


Section  1 


ARRAY  ITWO 


Each  section  Is  referred 
to  as  a  Col  urn.  Each  Column 
has  the  same  number  of 
rows.  The  array  Is  broken 
down  Into  a  fixed  number  of 
"columns." 


(a) 


(b) 


Figure  IIX-11.  Breakdown  of  r  Pseudo-TVo-DiiaensionsLl  /;^*ny . 
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5-2;  Pseudo-Tue  Dimensional  Arrays . 

In  this  bectif'n  the  information  in  the  pseudo-tvo- dimen¬ 
sional  arrays  is  described.  This  information  may  be  accessed  by 
system  module  user  coda  at  any  time.  If  actions  are  taken  at  a  task 
node  in  a  syax.es  module  which  would  cause  any  of  these  array 
elements  to  change  values,  the  analyst  must  set] 
values  in  user  code  celled  by  that  task  node. 


the  appropriate 


5-2, a.  Track  Information.  Track  information  is  kent  in 
the  two  arrays  HTRACK  and  S3.  Both  are  treated  as  pseudo-tvo- dimen¬ 
sional  arrays,  and  both  have  the  same  number  of  columns.  Each  track 
has  a  column  in  HTRACK  and  a  column  in  SS,  and  both  arrays  use  the 
same  coliann  number.  This  column  number  vill  be  used  in  system  module 
user  code.  Some  of  the  values  in  STRACK  vill  be  set  automatically  by 
the  Control  system  module,  while  the  MOPADS  analyst  vill  set  other 
values.  The  column  assignments  vill  be  done  automatically.  The 
STRACK  array  is  always  equivalence!  to  the  array  XTRACK  so  that  each 
element  may  be  either  real  or  Integer.  MSAIHT  vill  automatically  update 
the  contents  of  the  SS  array.  The  SS  array  has  no  pointer  row 
because  it  uses  the  same  column  number  as  HTRACK. 

i 

i 

See  Figure  III -12  for  a  complete  description  of  the  track 
information  storage  arrays. 

5-2 .h.  Site  Information.  A  site  ic  either  a  special 
radar,  a  transmittable  Q-73,  or  a  nou-transmittable  critical  site, 
such  as  an  airfield,  ammunitions  depot,  encampment,  or  command  center. 
Sites  do  not  usually  come  and  go,  but  they  may.  A  site  that  vas 
destroyed  any  be  removed  from  the  HSITE  array.  HSTTE  is  equivalenced 
to  XSITE  in  each  routine  which  has  the  labeled  common  block/C0M26/. 

See  Figure  III-13  f«w  a  complete  description  of  the  site  infor¬ 
mation  storage  arrays. 


5-2. c.  Fire  Unit  Information.  A  fire  unit  s  an  air 
defense  unit  arme£  with  missiles  or  other  firepxwer  vi  ie  purpose 
of  destroying  enesqr  aircraft  to  protect  itself  and  critic-1  assets. 
Each  fire  unit  has  a  column  in  the  ITFSTOR  array. 

See  Figure  Ill-lh  for  a  complete  description  of  the  fir*  unit 
information  storage  arrays. 

5-2.d.  Conaon  Information.  Each  track,  site,  or  fire 
unit  may  have  a  five-character  alphanumeric  identifier.  These  ore 
stored  in  the  character  array  HTRID.  A  companion  array  NTRID2,  which 
is  dimensioned  to  the  same  number  of  columns  as  RTRID,  contains  cross- 
referencing  information  to  find  the  appropriates  data  in  the  NTRACK, 
HSITE,  or  WFSTOR  arrays  given  the  alphanumeric  Identifier.  Columns 
may  be  added  or  removed  from  NTRID/HTRID2  just  as  with  the  other 


H-52 


■JHENKTiY.' 


KROWS  -  17 
KCOLS  -  200 
NSSRW  -  5 

NXTTR  ■  Available 
Column 
Pointer 


fTMCX  ROW  EFIMTIOKS 


1.  Pointer  to  HTRID/NTRIL2  array. 

2.  X  -  DIRECTION  COMPONENT  OF  THE  VELOCITY  (I  IN  KNOTS) 

3.  Y  -  DIRECTION  COMPONENT  OF  THE  VELOCITY  (V  IN  KNOTS) 

A.  2  -  DIRECTION  COMPONENT  OF  THE  VELOCITY  (j  IN  FT/MIN) 

5.  Actual  primary  ID  (1-Friendly,  2-Hostile,  3-Other), 

*6.  Row  I  IN  DATA  RASE  FOR  CHECKPOINT  PROCESSING, 
gj  J  IFF  DATA  (YET  TO  BE  DEFINED,  CURRENTLY  UNUSED). 

9.  Copy  row  I  of  the  unit  the  track  is  local  to  (0  if  none). 

10.  Column  in  NSITE  of  the  viewer  that  sees  the  track(0  if  unseen). 

11.  Current  track  ouautv  (not  defined,  unused). 

12.  Track  size 

*13.  Air  scenario  track  ID. 

14.  Aircraft  type 

15.  Jamming  (unused,  1-Yes,  2-No). 

16.  Is  THE  END  OF  SEGMENT  A  TARGET?(l-YES,  2"No) 

17.  Pointer  variable  for  next  available  column. 

ROW  DEFINITIONS 

1.  X  Position 

2.  Y  Position 

3.  Z  Position 

5*1  Unused 


*  Used  internally,  not  to  be  accessed  or  set  by  the  analyst. 


Figure  III-12.  Track  Information  Storage. 
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The  Column  nunber  - - 

Is  the  Internal 
site  ID 


1 

r~ 

2 

3 

_ 4 

•  •  •  • 

MNCL 

m 

KS 

£5 

999959 

591 

M';RW  • 
MNCL  - 
NSPTR  » 


11 

100 

Available 

Column 

Pointer 


NSITE/XSITE 


NSITE  ROW  DEFINITIONS 


1.  Pointer  to  NTRID/NTRID2  arrays. 

2.  Site  type  (1-Protected  assets,  2-Remote  Radar, 

3-A1r  defense  unit  other  than  FU’s) 

3.  X-coordinate 

4.  Y-coordinate 

5.  Z-coordlnate 

6.  Transmittable  (1-Yes,  O-Nj) 

1.  Active  Status  (1-Active,  O-Inactlve) 

8.  Copy  row  number 

If  type  =1,  of  the  FU  assigned  to  protect  this  asset 

If  type  *2,  of  the  unit  owning  the  viewer  (radar) 

If  type  s3,  of  the  air  defense  unit 

9.  Pointer  to  ND6AD  for  viewer  06  address 

If  type  =2,  0  otherwise 

10.  Viewer  number.  If  type  f  1  or  3 

11.  Available  column  pointer 


Figure  111-13.  Site  Information  Storage. 


The  Column  number-. 
Is  the  FU 
Internal  ID 
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MFROW 


1 

2 

3 

.  .  .  .  N 

•  •  •  « 

rC0LS 

‘II 

72 

^7777777 

z2 

MFROW  • 
NFCOLS  " 
NFSPT  • 


25 

30 

Available 
Column  Pointer 


NFSTOR/XSTOR 


FU 

Status 
of  Fire 
Sac t Ion 

A 


y  3. 

14. 

15. 


17-24 

25. 


NFSTOR  BOW  DEFINITIONS 

Pointer  to  the  NTRID/NTRID2  arrays 
Copy  row  nunber 

Syste*  Nodule  Type  of  the  FU  (e.q.,  4-ZltAWK) 

X  coordinate 
¥  coordinate 

12  coordinate 

Defended  Sites  (column  masters  in  NS1TE  array) 

Niaaber  of  hot  Missiles 
Number  of  cold  Missiles 
Alert  Status  (unused) 

Fir.  Action  Status  (for  HAHK,  the  codes  are  as  follows: 
1-Ready,  2 -Weapon  assigned,  3-Ackncaledge, 

4-Track  Ing,  5-Firing,  6-£ffect1ve, 

/•Broken  engagement,  8-Not  effective. 

9-Partlally  effective,  10-All  Missiles  expended, 

11-Out  of  action,  12-Hot  Missiles  expended) 

Primary  track  assignment  (cplunn  number  In  NTRACK, 
i  If  none)  (negative  implies  cover  command) 

Seconda^  track  assignment  {column  number  In  KTRACK, 
i  if  none)  (negative  Implies  cover  cmnaiand) 

Current  track  being  engaged  (coltann  number  In  NT  RACK, 

9  If  none) 

Current  cowwnd  (for  IHAFK,  the  codes  are  as  follows: 
1-Engage,  2-Engage  ripple,  3-Invest1g&ge/Ass1gn, 
4-Cover,  5-tkiused,  6-Hold  fire,  7-Cease  fire, 

8-Cease  engage,  6-No  command) 

•Repeat  of  rows  9-16  for  Fire  Section  8 
Available  coliaw  pointer 


Figure  III-lk.  Fire  Unit  Information  Storage. 
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pseudo-two-dimensional  arrays.  CuI'wib  arc  pointed  to  by  the  first 
row  element  in  either  ETRACK,  NSiTE,  or  KFSTOR. 

See  Figure  III-15  for  a  full  description  of  the  usage  of  the 
of  the  NTRID/KTRID2  arrays. 

5-3.  Copy.  Systan  Module,  and  Operator  Data. 

The  MSAINT  simulation  program  has  a  current  entity  it  is 
processing.  This  entity  is  either  an  operator  or  a  non-operatov 
control  entity.  Each  entity  belongs  to  a  copy,  which  has  a  copy  row 
number  (the  row  number  in  the  NCOFY  array).  Each  entity  also  has 
associated  with  it  a  systan  module  type.  Hierefore,  each  entity, 
while  it  is  current,  also  has  a  current  copy  row  number  and  current 
system  module  number. 

Several  variables  in  common  can  be  accessed  by  the  user.  These 
are  defined  in  Table  III-3. 

Some  of  the  copy-related  information  accessible  to  the  MOFADS 
analyst  is  stored  in  the  NCOFY  array.  See  Figure  III-16  for  a^ 
complete  description  of  the  NCOPY  array.  It  is  not  a  pseudo-two¬ 
dimensional  array.  The  copy  row  number  referred  to  throughout  this 
document  is  the  row  number  in  the  NCOPY  array. 

Some  operator-specific  information  is  stored  in  the  NOPRI 
array.  It  is  defined  in  Figure  III-17. 

5-1* .  Display  Information. 


Each  operator  is  assumed  to  have  some  type  of  visual  tv 

display  panel  which  provides  information  about  the  current  air 
defense  battle.  These  displays  may  have  one  or  more  options  which 
affect  how  the  system  information  is  displayed  and  which  information 
is  displayed.  These  options  are  stored  in  the  RSCRN  array.  Each 
operator  may  have  up  to  10  display  options.  The  row  dimension  of 

the  NSCRN  array  is  the  operator  ID.  The  column  definitions  depend  £•' 

on  which  type  of  operator  it  is.  Figure  IIT-18  shows  the  structure  v. 

of  NSCRU  and  gives,  as  an  example,  the  screen  data  for  AN/TSQ-73  ■'> 

operators.  v| 


5-5.  Data  Base  Addresses. 

In  order  to  reference  data  in  the  MOPADS  data  base  (DB) 
from  MSA.INT,  various  DB  addresses  must  be  accessible.  These  are 
stored  in  several  arrays  which  depend  on  the  ur,~ge  of  the  DB  address. 

Several  types  of  DB  addresses  are  stored  in  the  NDBAD  airay. 
These  are  pointed  to  by  the  values  in  columns  20-22  of  the  NCOPY 
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Column  pointed 
to  by  NTRACK, 
NSITE  and 
NFSTOR  arrays 


NTRID 


1 

CVI 

3 

4 

K 

FRID 

3 

4 

hf 

TRIP 

1 _ _ 

2 

MWTRD 

NTRID2 


MMTRD  *  3 

MTRID  =  300 

NXTID  *  Available 
Colimn 
Pointer 


NTRID  ROW  DEFINITION 

1.  £-character  alphanumeric  label  (NTRID  is  a  character  array) 


NTRI02  ROW  DEFINITIONS 

1.  Type  of  air  defense  component  (1-Track,  2-Site,  3-Fire  unit) 

2.  Column  number  in  NTRACK,  NSITE,  or  NFSTOR. 

3.  Available  column  pointer 
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Figure  III-15.  Common  Information  Storage. 
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Table  III-3.  MSAINT  Common  Definitions 


VARIABLE 

NAME 

COMMON 

BLOCK 

DEFINITION 

MMCPY 

COM2  5 

Maximum  copy  number  (currently  -  30) 

MMSYS 

COM26 

Maximum  system  module  nunrber 
(currently  -  k) 

NCTJRS 

C0M2T 

The  current  system  module  number 
during  input.  Not  used  during  the 
execution  of  the  simulation. 

NCURCO 

COM28 

The  current  copy  row  number  (for  the 
current  entity).. 

NCURSY 

COM28 

The  current  system  module  number 
(during  the  simulation). 

ISTATZ 

COM2  8 

A  flag  used  to  indicate  if  the 
current  entity  is  an  operator  or  not 
=1  current  entity  is  an  operator 
=2  current  entity  is  not  an  operator 

NMCOP(U) 

COM26 

NMCOP(i)  is  the  number  of  copies  of 
system  module  type  i 

NEGID(150) 

COM26 

NFGID(i)  is  the  copy  number  of  the 
entity  with  ID  =  -i 

MMNEG 

COM26 

Maximum  array  dimension  of  the 

NBGID  array 

NCNEXT 

COM2  7 

Next  available  row  in  NCOPY 

Row  #  is 

THE  CoHy 

Number 


15 

20 

26 

30 


ASSOCIATED  POIJTER  VARIABLE  DEFINITIONS 

I  ‘  “ 

MNCPY  -  Maximum  number  of  copies,  used  as  the  maximum  row  dimension 
(currently  -  30) 

LFOP  -  Pointer  to  the  first  column  containing  operator  id's 
(currently  -  15) 

LFDB  -  Pointer  to  the  first  column  containing  data  base  addresses 
(currently  -  20) 

MCCOL  -  Maximum  column  dimension  of  NCOPY  (currently  -  26) 


COLUMN  DEFINITIONS 

1.  4-digit  copy  identifier 

2.  Pointer  to  NSITE  or  NFSTOR 
<0  »  column  number  in  NSITE 
>0  *  column  number  in  NFSTOR 

3.  System  module  type  (1-Control,  2-6roup  Q-73,  3-Battaliom  (3-73, 

A- I HAWK) 

A.  Higher  command  (copy  row  numbers) 

5-14.  Subordinate  units  (copy  row  numbers) 

15-19.  Operator  id's  for  opemtors  in  this  copy 

20.  Pointer  to  task  data  DB  address  in  the  ND3AD  array 

21.  Pointer  to  ESV  data  18  address  in  the  NDCAD  array 

22.  Pointer  to  MOPADS  resource  address  in  NDBAD 

23.  Pointer  to  track  data  DB  address  in  NDBAD 

24.  Index  of  this  copy  within  system  module  type  (1,2,...) 

25.  Copy  Sampling  Option  (1-‘(nmoderated  deterministic,  2-Unmoderated 

s.ochastic,  3-Moderated  deterministic, 
4-Moderated  stochastic) 

26.  Column  number  in  the  NTRID/NTRID2  arrays 


Figure  III-16.  NCOPY  Array  Description. 
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5  -  I HAWK  ASO 

6  -  IHAWK  FCO  A 

7  -  IHAWK  FCO  B 

8  -  GROUP  TD1 

9  -  GROUP  TD2 

Number  of  message  currently  addressed  to  the  operator. 


r. v 


Figure  IIT-17.  NOPRI  Array  Description. 
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The  row 
number  Is 
the  operator 
ID 


MOPR  =  150 


NSCRN 


EXAMPLE 

:  COLUMN  DEFINITIONS  FOR  Q-73  OPERATORS 

1. 

The  current  hooked  item  (column  number  in  NTRID2) 

2. 

Velocity  vectors  or  TTG  Vectors  (0-Neither,  1-Velocity 

Vectors,  2-TTG  Vecto 

3. 

Screen  Alphanumerics  (0-off, 

1-on) 

4. 

Engagement  Markers  (0-off,  1-on) 

5. 

Pairing  Lines  (0-off,  1-rn) 

6. 

Map  (0-off,  1-on)  j 

i 

7. 

Screen  Range  (n.mi.) 

8. 

X  position  of  screen  center 

9. 

Y  position  of  the  screen  cenl 

;er 

10. 

Unused 

NOTE:  Elements  7,  8,  and  9  of  Display 
as  above  for  all  system  modules. 

information  must  be  defined 
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Figure  III-18.  NSCRN  Array  Description  for  Q-73  Operators. 
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array,  see  Figure  III-16.  NEB AD  has  two  rows  since  tnese  DB 
addresses  require  two  words.  The  variable  MXDBD  is  the  maximum 
column  dimension  of  NDBAD. 

One  Inward  DB  address  is  stored  in  the  NMES  array .  This 
address  points  to  the  message  directory  in  the  DB, 


Two  4-word  DB  addresses  for  each  copy  are  stored  in  the  NDE4 
array.  For  a  full  description  of  the  NDB4  array  see  Figure  III-19. 

5-6.  Miscellaneous  Variables. 

Several  miscellaneous  variables  were  added  to  MSAINT 
common  to  represent  general  information.  These  are  defined  in 
Table  111-4. 

6-0  MISCELLANEOUS  ADDITIONS  TO  SAINT 

Several  miscellaneous  changes  were  made  to  SAINT.  These  are 
described  below. 

1.  Comment  Car  ds 

Formerly  in  SAINT,  when  a  data  card  had  an  asterisk( *) 
in  column  1,  it  was  interpreted  as  a  FIN  card.  This  precluded  the 
capability  of  inserting  comment  cards  into  the  data  input  deck. 

This  feature  wa-  modified  so  that  now,  if  an  asterisk  is  placed  in 
column  1,  the  card  is  ignored.  Thus,  all  comment  cards  must  have  an 
asterisk  in  column  1.  Comments  can  also  be  placed  on  any  data  card 
after  the  asterisk  which  terminates  the  data  fields. 

2.  New  Trace  Option 

MSAINT  no  longer  prints  out  an  iteration  trace  for  the 
beginning  and  end  trace  run.  Instead,  rows  of  date,  are  written  out 
to  an  external  file  when  each  significant  event,  occurs.  The  MOPADS 
data  base  references  this  file  to  produce  specialized  traces  as 
specified  by  the  MOPADS  user.  See  Folito  (l2.&3b)  for  a  complete 
description  of  the  MOPADS  user  trace  output  options. 

3.  Handling  of  Statistics 

MSAINT  no  longer  prints  out  cny  simulation  statistic 
output.  Instead,  MSAINT  merely  collects  the  statistics  in  internal 
arrays.  These  arrays  are  then  stored  in  the  MOPADS  lata  base  either 
at  the  end  of  each  run  or  at  the  end  of  the  simulation.  MOPADS  uses 
these  arrays  to  calculate  and  print  out  the  statistics  requested  by 
the  MOPADS  user.  The  MOPADS  user  will  always  get  standard  statistics 
such  as  overall  system  performance  erasures,  but  most  statistics  will 
be  optional.  For  a  complete  description  of  MOPADS  statis^c  output 
options,  see  Polito  (l>33b). 


TYPES  OF  DE  ADDRESSES 
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» 


(-,1-)  -  Copy  directory  DB  address 

(-.2,-)  -  CB  address  for  messages  that 

require  responses 


> 


*  * 
r. 
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Figure  III-19.  BTfBk  Array  Description. 
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Table  111-4. 

Miscellaneous  Variable  Definitions. 

g-H 

Start  time  of  the  simulation  (minutes) 

TFISK 

£ftd  time  of  the  simulation  (minutes) 

DETjT 

Time  between  checks  for  updates  on  aircraft 
checkpoints. 

LASTM 

The  last  message  number  used.  (Message 
numbers  are  internally  assigned. ) 

NXMON 

Month  of  the  simulation  run. 

BXDAY 

Day  of  the  simulation  run. 

NXYR 

Year  of  the  simulation  run. 

1JXPROJ 

8-character  project  name 

itxname 

8-character  MOPADS  user  name 
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1-0  STANDARD  MOPADS 

AIR  DEFENSE  SYSTEM 

AIR  DEFENSE  SYSTEM 
MODULE 


AIR  SCENARIO 


BRANCHING 


DATA  BASE  CONTROL 
SYSTEM 


DATA  SOURCE 
SPECIALIST 

ENVIRONMENTAL 
STATE  VARIABLE 


TERMINOLOGY 


ERMUIOLOGY. 

A  component  of  Air  Defense  which  includes 
equipment  and  operators  and  for  which  techni¬ 
cal  and  tactical  -raining  are  required. 

Examples  are  IHAVK  and  the  AN/TSQ-73. 

Models  of  operator  actions  and  equipment 
characteristics  for  Air  Defense  Systems  in 
the  MOPADS  software .  These  models  are  pre¬ 
pared  with  the  SAINT  simulation  language. 

Air  Defense  System  Modules  include  the  SAINT 
model  and  an  data  needed  to  completely 
define  task  element  time,  task  sequencing 
requirements ,  and  human  factors  influences . 

A  spatial  and  temporal  record  of  aerial 
activities  and  characteristics  of  an  air 
defense  tattle.  The  Air  Scenario  includes 
aircraft  tracks,  safe  corridors,  ECM,  and 
other  aircraft  and  airspace  data.  See  also 
Tactical  Scenario. 

A  term  used  in  the  SAINT  simulation  language 
to  mean  the  process  by  which  TASK  nodes  are 
sequenced.  At  the  completion  of  the  simulated 
activity  at  a  TASK  node,  the  Branching  from 
that  node  determines  which  TASK  nodes  will  be 
simulated  next. 

That  part  of  the  MOPADS  software  which  performs 
all  direct  communication  with  the  MOPADS  Data 
Base.  All  information  transfer  to  and  from 
the  data  base  is  performed  by  invoking  the  sub¬ 
programs  which  make  up  the  Data  Base  Control 
System. 

A  specialist  in  obtaining  and  interpreting 
Army  documentation  and  other  data  needed  to 
prepare  Air  Defense  System  Modules. 


An  element  of  an  Environment al  State  Vector. 
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ENVIRONMENTAL 

STATE  YECTOR 

An  array  of  values  representing  conditions  or 
characteristics  that  nay  affect  store  than  one 
operator.  Elements  of  Environmental  State 
Vectors  nay  change  dynamically  during  a  MOPADS 
simulation  to  represent  changes  in  the  environ¬ 
ment  conditions. 

MODERATOR  FUNCTION 

A  matbematical/logical  relationship  vhich 
alters  the  nominal  time  to  perform  an  operator 
activity  (usually  a  Task  Element).  The  nominal 
time  is  changed  to  represent  the  operator's 
capability  to  perform  the  activity  baaed  o*.  the 
Operator's  State  Vector. 

MOPADS  DATA  BASE 

A  computerized  data  base  designed  specifically 
to  support  the  MOPADS  software.  The  MOPADS 

Data  Base  contains  Simulation  Data  Set(s).  It 
communicates  interactively  vith  MOPADS  Users 
during  pre-  and  post-run  data  specification  and 
dynamically  vith  the  SAUIT  software  during 
simulation. 

MOPADS  MODELER 

An  analyst  who  will  develop  Air  Defense  System 
Modules  and  modify/develop  the  MOPADS  software 
system. 

MOPADS  USER 

An  analyst  who  vill  design  and  conduct  simu¬ 
lation  experiments  with  the  MOPADS  software. 

MSA I NT ( MO  PADS/ SAINT) 

The  variant  of  SAIIJT  U3ed  in  the  MOPADS  system. 
The  standard  version  of  SAINT  has  been  modified 
for  MOPADS  to  permit  shareable  subnetworks  and 
more  sophisticated  interrupts.  The  terms  SAUIT 
and  MSAINT  *re  used  interchangeably  when  no 
conf vision  will  result.  See  also,  SAINT. 

OPERATOR  STATE 

VARIABLE 

One  element  of  an  Operator  State  Vector. 

OPERATOR  STATE 

VECTOR 

An  array  of  values  representing  the  condition 
and  characteristics  of  an  operator  of  an  Air 
Defense  System.  Many  values  of  the  Operator 
State  Vector  will  change  dynamically  during 
the  course  of  a  MOPADS  simulation  to  represent 
changes  in  operator  condition. 
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OPERATOR  TASJC 


An  operator  ac.iTity  identified  inring 
veapeas  system  front-end  analyses. 


SAINT 


TION  DATA  SET 


SIMULATION  STATE 


SYSTEM  MODULES 


The  underlying  computer  simulation  language 
used  to  model  Air  Defense  Systems  in  Air 
Defense  System  Modules.  SAINT  is  an  acronym 
for  Systems  Analysis  of  Integrated  Networks  of 
Tasks.  It  is  a  veil  documented  language  designed 
specifically  to  represent  human  factors  aspects 
of  man /machine  systems.  See  «J.so  MSAUJT. 


The  Tactical  Scenario  plus  all  required  simu¬ 
lation  initialization  and  other  experimental 
data  needed  to  perform  a  MOPADS  simulation. 


I 

At  any  instant  in  time  of  a  MOPADS  simulation 
the  Simulation  State  is  the  set  of  values  of  all 
variables  in  the  MOPADS  software  and  the  MOPADS 
Data  Base. 


See  Air  Defense  System  Modules. 


TACTICAL  SCENARIO 


The  Air  Scenario  plus  specification  of  critical 
assets  and  the  air  defense  configuration 
(number,  type  and  location  of  weapons  and  the 
command  and  control  system). 


TACTICAL  SCENARIO 
COMPONENT 


An  element  of  a  Tactical  Scenario j  e.g. ,  if  a 
Tactical  Scenario  contains  several  Q-T3's,  each 
one  is  a  Tactical  Scenario  Component. 


See  Operator  Task. 


TASK  ELEMENTS 


Individual  operator  actions  which,  when  grouped 
appropriately,  mak''  up  operator  tasks.  Task 
elements  are  usually  represented  by  single 
SAINT  TASK  nodes  in  Air  Defense  System  Modules. 


« 


I 
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TASK  NODE 

A  modeling  symbol  used  in  the  SAINT  simu¬ 
lation  language.  A  TASK  node  represents 
an  activity;  depending  upon  the  modeling 
circumstances,  a  TASK  node  may  represent 
an  individual  activity  such  as  a  Task 
Element,  or  it  may  represent  an  aggregated 
activity  such  as  an  entire  Operator  Task. 

TASK  SEQUENCING 
MODERATOR  FUNCTION 

A  mathematical/logical  relationship  which 
selects  the  next  Operator  Task  which  an 
operator  will  perform.  The  selection  is 
based  upon  operator  goal  seeking 
characteristics. 

2-0  OTHER  TERMINOLOGY.. 

ACC 

ADSM  Code  Character. 

ADSH 

Air  Defense  System  Module. 

DATA  BASE 

The  collection  of  user  information  and 
control  information  that  is  processed  by 
the  DBC3. 

DATA  BASE  FILE 

A  computer  file  stored  on  disk  that 
contains  the  data  base. 

DATA  LIST 

A  list  of  values  (character  or  numeric) 
that  is  user  specified  and  is  stored  in 
a  data  base. 

DB 

Data  Base. 

DECS 

Data  Base  Control  System. 

DBF 

Data  Base  File. 
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DIRECTORY 


A  collection  of  data  lists  and  other 
directories. 


DL 

Data  List. 

DR 

Directory. 

ID 

Identify.  DL's  and  DR's  have  identifiers 
that  are  lists  of  integers  and  are  stored 
in  their  owning  directory. 

/ 


1.  INTRODUCTION 


.1-0  PURPOSE. 

This  document  describes  the  procedure  for  entering  reference 
Air  Defense  System  Modules  (ADSM)  into  a  MOPADS  data  base.  It’s 
a  user  manual  for  the  "Create/Edit  Reference  System  Module"  subprocess 
of  the  MOPADS  user  interface.  The  need  for  this  rubprocess  arises 
when  a  MOPADS  modeler  has  developed  a  MOPADS  model  of  an  air  defense 
system.  Guidelines  for  developing  system  modules  is  described  in 
MOPADS  Volume  h.3  and  U.k  (Walker  &  Polito  ( 1983a ,b). 

When  the  information  for  the  system  module  has  been  developed, 
the  MOPADS  modeler  is  ready  to  enter  the  information  into  a  MOPADS 
data  base.  That  is  the  purpose  of  the  "Create/Edit  Reference  System 
Module"  subprocess.  This  subprocess  has  facilities  for  entering 
and  editing  all.  of  the  data  associated  with  a  system  j>odule  that  is 
contained  in  the  data  base.  In  particular,  the  following  information 
is  entered  and  edited  with  this  subprocess: 

1.  Operator  State  Vectors 

2.  Environment  State  Vectors 

3.  Task  Data 

U.  System  Resource  Data 

The  system  module  should  be  completely  designed,  the  MSAINT  model 
developed,  and  the  user  code  written  before  this  subprocess  iB  used  to 
enter  data  in  the  data  base.  The  next  section  describes  the  informa¬ 
tion  needed  to  create  a  reference  ADSM. 


2-0  INFORMATION  NEEDED . 

The  data  required  to  enter  a  reference  ADSM  are  contained  in 
Figures  1-1  through  1-6.  The  operator  nrnbers  and  labels  are  fros 
(l)  and  (?)  in  Figure  1-1.  If  system  hardware  resources  are  included 
in  the  model  (as  opposed  to  MSAINT  resources)  these  may  be  found  in 
©  of  Figure  1-1  or  ©  of  Figure  1-2 ,  depending  upon  how  the  MOPADS 
modeler  has  chosen  to  enter  them. 

Each  operator  will  be  a  SAINT  entity,  and  the  node  where  he  is 
created  can  be  found  in  Figure  1-2,  ©.  Goal  defintiions  and  para¬ 
meters  will  have  been  entered  in  the  forms  in  Figures  1-3  and  I-U. 
Each  system  operator  may  have  a  set  of  display  parameters  which  will 
be  found  in  Figure  1-5. 
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RANGE  OF  I  LOU  POINT  1  1  LOU  POINT  2  I _ HIGH  POINT  1  I  HIGH  POINT  2 


PARAMETER  INITIAL 

NUMBER  DESCRIPTION  VALUE 


wi.  a.: 


Finally,  each  Task  Dode  will  have  an  associated  form  shown 
in  Figure  1-6  from  which  Task  data  will  be  entered  into  the  data 
base.  The  required  data  are  noted  by(l)  through 

When  the  system  module  is  created,  default  values  for  para¬ 
meters  in  the  operator  and  environmental  state  vectors  will  be 
loaded  into  the  data  base.  See  Laughery  &  Gavron  (1983).  Changes  to 
these  defaults  may  be  entered  using  the  editing  features  of  the 
subprocess. 

Tables  1-1  and  1-2  show  the  structure  of  portions  of  the 
MOPADS  day'  base  of  concern.  The  REFER  EH  CE-ADSM  directory.  Table  1-1, 
is  owned  Dy  the  master  directory  and  it  owns  all  of  the  reference 
ADSM  directories.  These  code  11  directories  are  shown  in  Table  1-2. 
The  various  data  lists  in  these  directories  are  explained  below. 

This  data  list  contains  information 
for  each  task  node  in  the  model  of 
the  system  module.  It  contains 
one  row  per  task  node. 

This  data  list  contains  information 
on  each  hardware  resource  defined 
for  the  ADSM. 

This  data  list  contains  the  label 
of  each  defined  hardware  resource. 

These  data  lists  are  the  operator 
state  vectors  for  the  operators. 

This  is  the  environmental  state 
vector  for  the  ADSM. 

This  data  list  contains  the  operator 
labels  and  the  task  nodes  where  they 
are  created. 

MOPADS  Volume  5.17  (Polito  (1983a))  contains  details  of  the  contents  of 
these  data  lists. 


TD-TASK-DATA 

R-ADS-RESOURCES 

RL-RESOURCE-LABELS 

OP-OPERATOR-STATE-VECTOR 

EN-ENVIRONMFNT-STATE-VEC 

OT-OPERATOR-TYPES 
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DIRECTORY  CODE: 


DIRECTORY  LABEL  I _ R^RINCE-ADSN _ 


BIRECTORY  COBEl _ J1 _ 

BIRECTORY  LABEL* _ Hsf£  RflBEfBft  M§lj 
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II.  COMMANDS  AVAILABLE 


1-0  BASIC  DATA  BASE  COMMANDS. 

The  basic  data  base  commands  that  are  available  in  all  sub¬ 
process  of  the  User  Interface  are  also  available  in  this  subproceos. 
Descriptions  of  these  commands  are  repeated  in  Appendix  A  for  easy 
reference. 


2-0  THE  ADD  COMMAND. 


The  specification  for  the  ADD  command  is  shown  in  Tablle  II-l. 
The  ADD  command  creates  a  new  reference  ADSM  directory  with  the  label 
specified  by  the  response  to  the  prompt  "ADGM. H  The  label  kust  be 
unique  and  must  have  the  form  of  a  one  character  ACC  followed  by  a 
dash  (-)  followed  by  the  ADSM  label  (e.g.,  "Q-BATTALI0N-QT3") .  The 
ADD  camnand  will  query  the  user  for  information  to  complete  the 
creation  of  the  system  module. 


The  ADD  command  creates  the  shell  of  a  system  module  with  all 
default  parameters  and  no  task  or  resource  data  entered.  This 
additional  information  and  changes  to  defaults  are  entered  with  the 
CHANGE  command.  The  ADD  command  leaves  the  created  ADSM  as  the 
current  directory. 


3-0  THE  CHANGE  COMMAND.  * 

The  CHANGE  command  is  shown  in  Table  II-2.  The  single  prompt 
requests  the  type  of  data  in  the  current  reference  ADSM  to  edit. 
Depending  upon  the  response  (TD,  R,  OP,  or  EN) ,  the  user  enters  an 
editor  to  modify  that  type  of  data.  i 

V  1 

Prior  to  exiting  the  CHANGE  command,  the  user  is  asked  if  a 
line  printer  list  is  desired  of  the  particular  DL.  This  feature 
permits  hard  copy  records  of  the  entire  reference  ADSM  to  be  main¬ 
tained  and  cross-checked  with  desired  values  from  Section  I.  The  speci¬ 
fied  data  list  becomes  the  current  data  list  and  remains  current  on 
exit  from  the  CHANGE  command. 


U-0  THE  DELETE  COMMAND. 


The  DELETE  camnand  is  Bhovn  in  Table  II-3.  The  DELETE  command 
will  irrevocably  remove  an  entire  reference  ADSM  from  the  REFERENCE 


i 


i 


i 


> 


t  - 
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Table  II-l.  ADD  Cooaand  Specification 


Table  II-2.  CHANGE  Canwand  Specification 


COMMAND  DATA  SPECIFICATION 
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Table  II-3.  DELETE  Ccnmand  Specification. 


AD6M  directory.  Use  it  with  caution.  The  response  to  the  "ADSM" 
prompt  is  the  label  of  the  reference  ADSM  to  be  deleted.  The  DELETE 
command  will  function  on  either  the  working  or  reference  data  base. 


5-0  THE  GET  COMMAND. 

The  intent  of  the  MOPADS  DBCS  system  (Polito  (1983b))  is 
that  the  reference  data  base  be  used  to  store  stable  copies  of  infor¬ 
mation  such  as  reference  ADSM's.  When  needed  in  a  working  setting  to 
perform  particular  simulations,  the  information  ean  be  transferred  to 
a  working  DB.  The  GET  command  (see  Table  II-4)  copies  on  entire  ref¬ 
erence  ADSM  from  the  reference  DB  to  the  working  DB. 

The  response  to  the  single  prompt  is  an  ADSM  label.  It  is  copied 
to  the  working  DB  with  the  same  name  and  will  replace  an  existing  ADSM 
with  the  same  name.  The  user,  however,  will  be  prompt  id  for  approval 
to  overwrite  an  existing  ADSM. 


6-0  THE  RENAME  COMMAND. 

The  RENAME  command  specification  is  shown  in  Table  II-5.  RENAME 
will  change  the  label  of  a  Reference  ADSM  on  the  working  DB.  Note  that 
the  ADSM  Code  Character  (ACC)  may  not  be  changed.  Only  the  portion 
of  the  ADSM  label  following  the  ACC  may  be  changed.  See  Section  II, 

2-0  for  a  description  of  ADSM  labels. 


7-0  THE  SAVE  COMMAND. 

The  SAVE  command  (Table  II-6)  performs  the  reverse  operation 
of  the  GET  command.  It  copies  an  entire  reference  ADSM  from  the  working 
to  the  reference  DB.  It  will  also  overwrite  an  ADSM  of  the  same  name 
on  the  reference  DB  (but  It  will  ask  permission  first).  The  response 
to  the  single  prompt  is  the  label  of  the  ADSM  to  save. 


8-0  THE  USE  COMMAND 

The  USE  command  (Table  II-7)  makes  a  specified  reference  ADSM 
the  current  directory  on  the  specified  DB.  Certain  commands  operate 
on  the  "current"  directory  or  the  "current"  data  list.  For  example, 
the  CHANGE  command  edits  the  current  reference  ADSM.  Most  commands 
will  leave  an  ADSM  current.  For  example,  the  ADD  command  leaves  the 
created  ADSM  current.  The  USE  command  is  a  way  to  specify  which 
reference  ADSM  should  be  current. 
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Table  II-5.  RENAME  Command  Specification 


COMMAND  DATA  SPECIFICATION 
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It  is  always  possible  to  deterri ns  which  ADSM  iB  current  with 
the  CURRENT  command  (Appendix  A)  avi  to  see  which  ADSM's  sure  available 
with  Che  DIRECTORY  (also  Appendix  A)  command.  USE  is  provided  as  a 
convenience  for  this  subprocess;  it  is  a  specialized  version  of  the 
more  general  basic  conmiand,  SELECT  (once  again,  see  Appendix  A). 


III.  USER  INSTRUCTIONS  AND  EXAMPLES 


1-0  A  SIMPLE  EXAMPLE. 

The  contents  of  Table  III-l  present  a  brief  example  to  demon¬ 
strate  creating  and  editing  a  reference  ADSM.  Only  thoEe  portions  of 
the  forms  needed  to  create  the  system  module  are  filled  in  and  all 
of  this  data  is  hypothetical. 

A  reference  system  module  labeled  "E-EXAMPLE”  is  described.  It*s 
ACC  is  "E."  Two  operators  with  labels  "MISSION-DIRECTOR"  and  "MISSION- 
COORDINATOR"  are  defined.  All  of  the  required  data  for  these  operators 
and  data  for  three  Task  nodes  are  contained  in  the  forms  contained  in 
Table  III-l. 

The  subsequent  sections  contain  sample  terminal  sessions  with 
MOPADS.  Inp.it  typed  by  the  user  is  enclosed  in  boxes  to  distinguish 
it  from  information  printed  by  MOPADS. 


2-0  THE  ADD  COMMAND. 

Figure  III-l  shows  an  example  of  the  ADD  command.  The  annotations 
are  explained  below. 

This  section  shows  the  initial  interchange  with  MOPADS. 
MOPADS  requests  the  name  of  the  working  DB  and  asks  if 
it  is  a  previously  created  data  base  file.  If  not,  the 
file  is  initialized  to  be  an  empty  MOPADS  data  base. 


WARNING 

All  information  on  a  data  base 
file  will  be  lost  if  the  user  answers 
"NO"  to  this  question. 

If  a  nev  DB  is  being  created,  the  user  may  specify 
title  information. 

(i)  -  The  user  must  select  a  subprocess.  In  this  case, 
select  subprocess  5,  the  "CREATE/EDIT  REFERENCE 
SYSTEM  MODULE"  subprocess. 


OPERATOR 

NUMBER  OPERATOR  TITLE  MISSION  AND  DUTIES  EQUIPMENT 


Data 


Table  I1I-1.  (continued) 


T%ble  III-l.  (continued) 


( continued) 


Table  III-l.  (continued) 


SKILL  REQUIREMENTS  TASK  SPECIFIC  BATA  HSAIHT  RESOURCE 

(CKTESQRT.UEIGHT )  {CODE,  VALUE)  REQUIREMENTS 


Table  III-l.  (continued) 
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Table  III-l.  (continued) 


SKILL  REQUIREMENTS  TAS“,  SPECIFIC  DATA  NSAINT  RESOURCE 

(CATEGORY (UEICHT )  (CODE,  VALUE)  REQUIREMENTS 
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prompts  >  adsn 
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1:.??<^ATK  BATA  MUET  BE  ERTEECB  WITH  THE  CNAROE  COMMA  Ml 
RESOURCE  DATA  MUET  BE  ENTERED  MITM  THE  CHANGE 
COMMAND. 
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BO  YOU  WANT  TO  RE-ENTER  POINTS 
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IN  TASK  SEQUENCING 


Figure  III-l.  (continued) 
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Figure  III-l.  (continued) 
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The  command  prompt  is 


- ESTER  CR/ED  ADSM  COMMAND 

In  any  subprocess,  the  MENU  command  viJLl  list  all 
commands  currently  available.  The  subprocess 
commands  are  printed  (ADD  through  USE)  followed 
by  the  basic  data  base  commands  that  are  available 
in  all  subprocesses  ( CLOSE  through  MENU) . 

In  any  subprocess,  the  HELP  command  can  be  issued 
to  print  information  on  the  prompts  for  any 
command. 

The  ADD  command  is  issued  to  create  the  example 
ADSM.  MOPADS  queries  for  the  basic  ACN.  At 
this  time,  MOPADS  checks  for  duplicate  use  of 
the  ACC  ("E")  and  ACN  and  vill  re-prompt  or 
cancel  the  command  if  needed. 

Ta3k  node  data  (the  "TD"  data  list)  and  resource 
data  (the  VR"  and  "RL"  data  lists)  must  be  entered 
with  the  CHANGE  command. 

MOPADS  asks  for  the  number  of  operator  goals,  the 
number  of  display  parameters,  and  the  number  of 
operators.  A  single  set  of  goals  is  permitted 
for  the  ADSM  operators.  As  will  be  seen,  however, 
each  operator  need  not  have  all  of  the  goals,  so  it 
is  possible  to  have  operators  with  different  goal 
sets  in  a  single  ADSM.  Similarly,  each  operator 
may  have  different  display  parameters,  but  the 
maximum  number  of  display  parameters  for  any 
operator  must  be  specified  here. 

Begin  input  for  operator  1.  The  operator's  label 
and  the  MSAINT  Task  node  at  which  he  is  created 
must  be  specified. 

Goal  input  for  the  operator  is  requested  here. 

Note  that  the  user  is  queried  separately  for 
each  goal.  Also,  since  the  range  of  satisfaction 
of  the  goals  for  this  example  have  one  end  point 
at  +_  infinity,  (goal  state,  goal  priority)  pairs 
are  requested  only  for  the  non-infinity  side. 

MOPADS  performs  internal  consistency  checks  on 
the  entered  values. 


@  -  The  operator  may  only  consider  the  n  most 

dissatisfied  ooa^s  in  task  sequencing.  Enter 
n  here. 

@  -  The  labels  of  the  display  parameters  for  this 

operator  are  entered  here.  The  display  parameters 
are  those  which  the  MOPADS  modeler  has. represented 
in  his  MSAINT  model  of  the  ADSM. 


-  Repeat  for  operator  2. 


-  Default  values  for  environmental  state  vectors 
and  operator  state  vectors  have  been  set  by 
MOPADS.  They  can  be  edited  with  the  CHANGE 
command. 


At  this  point,  MOPADS  has  created  the  reference  ADSM.  Seme 
of  the  data  lists  have  not  been  populated  yet,  howe-insr.  See  Table 
1-2.  As  discussed  above,  the  "TD,"  "R",  and  "RL,"  data  lists  are 
empty,  and  the  "OP"  and  "EN"  data  lists  have  default  human  factors 
values . 


3-0  THE  CHANGE  COMMAND. 

3-1 .  CHANGE  Task  Data. 

The  CHANGE  command  has  subeditors  to  change  each  of  the 
data  lists  in  an  ADSM.  This  section  describes  editing  of  the 
TD-TASK-DA.TA  data  list.  Figure  IIX-2  is  an  interactive  session  to 
edit  this  data  list.  The  annotations  are  explained  below. 

(T)  -  The  CHANGE  command  specifies  that  the  "TD"  (task  data) 
data  list  is  to  be  edited.  Recall  that  the  ADD 
command  creates  this  DL  but  it  is  empty.  Information 
for  each  TASK  node  that  is  to  have  its  task  time 
moderated  or  which  specifies  system  resources  must  be 
entered  explicitly  with  this  command. 

(?)  -  Data  is  entered  by  specifying  a  code  character  for  the 
operation  to  be  performed.  The  code  characters  are: 

S  -  show  parameters  for  a  node 

M  -  print  the  menu  of  code  characters 

E  -  enter  data  for  a  new  node;  "E"  may  be 

used  only  once  fer  any  node  to  create  it 
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Figure  III-2.  CHANGE  Task  Data  Example. 
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Figure  III-2.  (continued) 
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C  -  change  par  asset  era  for  an  existing  node. 

"C"  auat  be  used  for  all  edits  of  a  node 
after  it  is  created  with  "B". 

Q  -  quit  editing  the  current  type  of  task  data 

When  defaults  are  appropriate  or  an  old  value  is  to 
be  left  unchanged,  type  an  asterisk  (•)  for  the  value. 

There  are  four  types  of  data  that  nay  be  specified  for 
each  node,  and  they  are  edlt*i  separately.  The  user  has 
chosen  to  begin  with  task  tLue  data. 

The  data  to  be  entered  for  task  data  is  node  number, 
distribution  type.  Bean,  and  standard  deviation.  The 
input  line  creates  node  10  with  distribution  type  10, 
mean  ■  0.1  and  standard  deviation  *  0.035.  The  values 
entered  must  be  separated  by  one  or  more  blanks  or 
commas.  They  need  not  line  up  under  the  labeled  colunns. 

MO  PADS  echoes  the  command  data  on  the  next  line.  The 
option  echoed  is  the  user  option  preceded  by  "S"  (for  Show). 
If  an  error  is  made  that  is  echoed,  the  "S"  will  be 
replaced  by  an  "X"  (e.g.,  "XE"). 

This  line  demonstrates  that  the  spacing  between  input  data 
elements  is  not  significant. 

When  using  the  "S"  option  (e.g.,  S  10),  only  the  node 
number  is  required. 


As  a  demonstration,  the  standard  deviation  of  node  10  is 
changed  to  0.0U  and  then  back  to  0.035*  Note  that  the 
asterisks  caused  the  distribution  type  and  the  mean  to 
be  unchanged. 


© 


The  option  menu  and  column  headings  have  been  printed 
again.  They  are  printed  every  15  lines  so  they  will 
always  be  visible  on  most  scrolling  screen  terminals. 

The  "C"  option  is  invalid  for  nodr  11  because  it  does 
not  exist.  The  "E  11  8"  line  creates  node  11  with 
distribution  8  and  default  mean  and  standard  de-v  Lation. 
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If  tne  *C'  option  sett  tbi-  distribution 
typ«  to  zero,  the  n.'  ie  is  deleted.  This  is  the 
only  way  a  node  can  be  deleted.  The  "E"  option 
can  be  used  to  re-create  a  node,  but  previous 
paraaeter  values  (e.g.,  ae&n)  will  be  lost. 

This  capability  is  used  to  delete  node  11. 
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The  "Q"  terminates  editing  of  task  time  data  and 
re-prints  the  data  type  menu. 

Begin  editing  task  specific  human  factors  para¬ 
meters.  The  10  categories  with  their  associated 
index  values  (l  through  10)  are  printed. 

This  "C"  c remand  Bets  paraaeter  5  to  one  and  para¬ 
meter  6  to  5.  Then  MOPADS  echoes  the  parameter 
values  for  node  10.  When  a  node  is  created,  it 
automatically  ha3  default  values  for  each  task 
specific  parameter.  All  10  current  values  are 
printed  each  time  the  node  is  referenced.  Dote 
that  in  the  echo,  parameter  5  has  value  one  and 
parameter  6  has  value  5» 

If  an  invalid  option  ("Cl6r')  is  specified,  MOPADS 
prints  the  option  menu. 


^  -  Begin  editing  skill  data.  One  skill  may  be  specified 
on  each  command  line.  No  skills  are  specified  for 
a  task  by  default.  All  Bkill  data  must  be  specified 
explicitly  with  the  CHANGE  command. 

(Q)  -  Skills  1?  and  IT  were  specified  for  node  10.  The 
command  "C  in  IT  0"  deletes  skill  IT  for  node  10. 
This  is  reflected  by  the  subsequent  "S  10"  command. 
Also,  existing  skills  may  have  there  weights  changed 
by  issuing  a  "C"  command  (e.g.,  "C  10  13  .8"). 

-  Incorrect  skills  were  entered  for  node  10,  and  the 
above  capability  was  used  to  remove  the  skills  from 
node  10  and  add  them  to  node  lU. 


Examine  skills  for  node  lh  rjid  be  cure  they  are 
correct  before  moving  on  io  node  16. 


-  Begin  to  edit  ADSM  reso-urce  data. 
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&  -  Ho  AD5M  recource  data  was  opacified  for  this  example, 
hut  for  completeness  resource  data  is  entered  for 
node  10  and  then  removed.  This  removal  is  accomplished 
by  issuing  a  "C"  command  with  resource  parameters 
equal  to  zero. 

^5)  -  Before  exiting  free  the  CHANGE  command,  a  listing  of 
task  parameters  may  be  obtained.  It  con  be  printed 
at  the  terminal  or  on  the  MOFADS  file  for  nan-interactive 
output.  These  listings  should  be  scrutinized  to  ensure 
correct  data  entry. 


3-2.  CHANGE  Operator  Data. 

Figure  III-3  shows  the  CHANGE  command  to  edit  Operator 
State  Vectors.  The  annotations  on  the  figure  are  explained  below. 

-  Three  types  of  data  are  contained  in  the  operator 
state  vectors  that  cam  be  edited  with  CHANGE. 

-  Begin  editing  human  factors  data.  There  are  65  human 
factors  data  elements.  The  user  can  display  any  of 
them.  Here  elements  20  to  25  are  selected. 


MOPADS  prompts  for  elements  to  be  edited  one  at  a 
time.  Both  the  label  and  value  nay  be  changed 
although  normally  there  is  little  utility  in 
changing  the  label  since  the  moderator  functions 
specify  human  factors  data  by  element  number.  Tnis 
however,  does  not  preclude  specialized  procedures, 
written  into  the  implementation  of  a  particular 
system  module  which  might  make  changing  a  label 
desirable . 


Use  the  asterisk  (*)  to  avoid  changing  existing 
values . 


When  done  editing,  type  zero  for  the  element  number. 
This  brings  up  the  display  option  again. 


New  values  for  elements  2h  and  25  are  shown. 


A  listing  may  be  obtained  when  done  editing  each 
data  type. 


Editing  goal  parameters  is  similar  to  editing  human 
factors  parameters  except  the  labels  may  not  be 
changed.  Also,  care  must  be  taken  in  changing  this 
data.  See  Polito  (1983c)  for  a  discussion 
of  goal  data. 
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Figure  III-3.  CHANGE  Operator  Data  Example. 
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Figure  III-3.  (continued) 
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Figure  III-3.  (continued) 
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Each  operator  goal  requires  15  goal  eleirents  (in  the 
example  there  are  3  goals,  hence  45  goal  elements). 

In  Figure  III-3,  elements  23  to  30  are  the  points  on 
the  goal  state  vs.  goal  priority  curve  input  by  the 
user  with  the  ADD  command.  Elemenxs  17  to  22  are 
computed  from  these  points  to  fit  exponential  curves 
to  the  points  , Polito  (1903c).  Ho  automatic  computa¬ 
tion  of  elements  17  to  22  is  performed  by  CHANGE.  In 
order  to  change  an  operator's  goal  curves,  these 
elements  must  be  computed  manual Ij  and  then  edited 
with  CHANGE. 

Two  objective  function  parameter!!  may  be  edited.  See 
Folito  (1903c)  for  a  discussion  of  these  parameters . 


The  operator  state  vectors  are  stored  with  pointers 
to  the  various  types  of  data  (i.e.,  human  factors,  goal 
parameters,  etc.).  See  @1  Thus,  the  human  factors 
data  begins  at  element  32  (0. 

To  find  human  factor  parameter  6,  for  example,  compute 
its  index  as  follows:  32+6-1  *  37.  Column  37  of  the 
operator  state  vector  is  human  factors  parameter  6. 

Similarly,  the  goal  parameters  start  at  column  97,  (R), 
and  the  objective  function  data  begins  at  column  142,(5!). 

Finally,  the  display  and  task  sjack  information  begins 
at  columns  144,  (l^) ,  and  147,  ©),  respectively.  These 
data  cannot  be  edited  because  they  change  dynamically 
during  simulations. 


CHANGE  Environmental  Data. 


Figure  III-4  is  an  example  of  editing  the  Environmental 
State  Vector  for  the  reference  ADSM. 

©&0  -  The  environmental  state  vector  contains  system  and 

human  factors  data.  Editing  is  performed  in  the  same 
way  as  for  human  factor  parameters  in  the  operator 
state  vectors. 


The  listing  is  also  in  the  same  format  as  the  operator 
state  vectors.  System  parameters  begin  at  element  2,  Qy, 
and  human  factors  data  starts  at  element  23,  (£). 
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Figure  III-U.  CHANGE  F.  dronmental  Data  Example. 
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System  resources  vere  not  defined  for  the  example,  but 
an  example  of  defining  such  data  is  given  in  Figure  III-5.  The  data 
which  may  be  specified  for  a  resource  is: 

Resource  number 

Number  of  Units  Available 

Mean  Time  Between  Failures  (MTBF)  (Hrs) 

Meanj  Time  To  Repair  (MIR)  (Hrs) 

Use  fode  (0  -  non -exclusive  use,  1-may  be  used  by 
only  one  operator! 

Status  (1  -  green,  2  -  amber,  3  -  red) 

Editing  is  performed  in  the  same  way  as  for  Task  data  and  the  listing 
(not  shown)  is  formatted  in  the  same  way. 


U-0  THE  USE  Alb  RENAME  COMMANDS. 

I 

Figure  Ilf-6  is  an  example  of  the  USE  and  RENAME  commands. 
The  USE  command  may  be  issed  at  any  time  in  the  "CREATE/EDIT 
REFERENCE  SYSTEM  MODULE'1  subprocess  to  make  a  specified  ADSM 
current.  Similary,  RENAME  may  be  issued  at  any  time  to  rename  an 
AL3M.  The  renamed  ADSM  becomes  current. 


The  annotations  on  Figure  xII-6  are  explained  below. 

0  -  When  entering  MOPADS  with  an"OLD"  data  base,  it  is 

most  often  done  to  edit  an  existing  reference  ADSM.  The 
CHANGE  command  requires  that  av»  ADSM  be  current. 

The  USE  command  is  issued  to  select  a  particular  ADSM. 

0  -  The  CURRENT  command  confirms  that  "E-EXAMPLE"  has 
become  current. 


© 


The  RENAME  command  renames  "E-EXAMPLE. "  Note  that 
the  ACC  ( "E"  in  this  case)  cannot  be  changed. 


The  CURRENT  command  confirms  the  RENAME. 


5-0  THE  SAVE,  GET,  AND  DELETE  COMMANDS . 

Figure  Ilt-T  shows  an  example  with  the  SAVE,  GET,  and  DELETE 
commands.  The  Annotations  are  explained  below. 

0)  -  A  reference  data  base  is  opened  for  the  example. 
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Figure  III-5.  CHANGE  System  Resource  Data  Example 
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Figure  III-6.  USE  and  RENAME  Example. 
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Figure  III-7*  SAVE,  GET,  and  DELETE  Example. 
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0  -  The  ADSM  "E-EXAMFLE"  is  saved  to  the  reference  DB. 
After  the  SAVE,  the  saved  ADSM  is  current  on  both 
the  working  and  reference  DB. 

0  -  Rename  "E-EXAMPLE'1  to  "E- RENAMED"  on  the  working  KB. 
(Note  that  RENAME  works  only  on  the  working  DB.) 

0  -  Nov  GET  a  copy  of  "E-EXAMPLE"  from  the  reference  DB. 
"E-EXAMPLE"  will  he • current  on  both  the  working  and 
reference  DB's  after  the  copy. 

0  -  PLINK  on  the  working  DB  to  the  "REFERENCE-ADSM" 
directory  so  it  can  be  examined. 

0  -  Look  at  the  "REFERENCE-ADSM"  directory. 

0  -  Both  "E- RENAMED"  and  "E-EXAMFLE"  are  present. 

NOTE 


They  both  have  the  same  ID! .  This 
is  not  a  desirable  situation  and 
points  out  that  this  is  a  contrived 
example.  In  practice,  only  one 
version  of  a  particular  ADSM  would 
be  used  in  the  working  DB. 

0  -  Delete  "E-REN AMED . "  It  is  not  recoverable  after  DELETE. 


© 


A  DIRECTORY  command  shows  that  "E-RENAMED"  is  gone. 


GET,  SAVE,  and  DELETE  require  substantial  computer  processing, 
and  the  user  should  be  prepared  for  a  delay  before  the  next  prompt 
is  printed  by  the  computer. 
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APPENDIX  A.  INTRODUCTION  TO  THE  MOPADS  USER  INTERFACE 


1-0  CONVERSING  WITH  THE  MOP-IDS  USTR  TIPEKFACE. 


Tne  MOPADS  User  Interface*  is  hierarchical  in  structure. 
It  consists  of  five  subprocesses  as  snovn  in  Figure  A-l.  Each  of 
the  subprocesses  has  its  own  set  of  capabilities  and  commands  to 
invoke  them.  The  subprocesses  are  described  in  separate  documents. 
In  addition,  a  set  of  Basic  Data  Base  Commands  are  provided  that  are 
available  in  all  subprocesses.  The  main  purpose  of  this  section  is 
to  explain  the  use  of  these  commands. 


1-2.  Syntax  Rules. 


The  User  Interface  is  primarily  a  command  driven  processor 
that  vaits  for  the  user  to  issue  instructions.  It  does,  however,  have 
aspects  of  menu  driven  systems  in  that  some  commands  result  in  menus 
being  presented  to  the  user.  Also,  the  command  processor  (FFSP  described 
in  Goodin  and  Polito  (3983)  permits  menu-like  presentations  of 
commands . 


t«t»ti/tDit  ttn*  iiahihi  cmit/nm  mnu/n» 
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Figure  A-l.  Oiganization  of  the  User  Interface. 
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The  regular  mode  for  entering  commands  is  shown  below. 


ccimmand>pramptlaresponsel/prompt2»response2/. . . 


The  commands  and  prompts  are  keywords  recognized  by  MOPADS.  The 
response;  are  particular  values  for  the  prompts.  For  example, 
consider  this. 


OPEN ,FILE*MOPADS.I(BF/STATUS=OLD 


OPEN  is  the  command.  FILE  and  STATUS  are  prompts  recognized  by 
MOPADS,  and  MOP  ADS .  E3F  and  OLD  are  values  for  the  prompts. 

Certain  prompts  for  a  command  may  have  default  values  that  will 
be  used  if  the  prompt  is  not  entered.  In  the  example  above,  another 
prompt,  DB,  specifies  which  data  base  is  to  be  associated  with  the  file. 
Its  default  is  WORKING,  so  by  not  entering  it  on  the  command  line, 
WORKING  is  automatically  selected.  If  the  default  value  is  not  desired, 
then  the  prompt  must  be  explicitly  entered  on  the  command  line. 

If  the  user  fails  to  enter  responses  to  all  required  prompts, 
MOPADS  will  interactively  prompt  for  them.  For  example. 


OPEN , STATUS= OLD 

FILE [NO  DEFAULT]  *  MOPADS.DBF 


After  processing  the  OPEN  command,  MOPADS  found  that  the  required 
prompt,  FILE, was  not  entered.  It  printed  "FILE  I  NO  DEFAULT]  ='*  to 
prompt  the  user  for  a  response.  If  the  last  non-blank  character  on  a 
command  line  is  a  dash  (-),  MOPADS  will  interactively  prompt  for  all 
unentered  prompts,  even  those  with  defaults.  For  example. 


OPEN .STATUS® OLD  - 
D3 IWORKING]  *  REFERENCE 
FILE (NO  DEFAULT]  =  MOPADS.DBF 


The  dash  caused  "DB [WORKING]®"  to  be  printed.  The  value  between  the 
brackets  is  the  default  for  the  prompt.  The  default  can  be  selected 
by  typing  "DEF"  as  the  response.  DIF  can  also  be  entered  on  the  command 
line;  e.g. 
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OPES  ,EB=DEF /STATUS=0LI>/PI1E«M0PADS  .DR? 


The  above  demonstrates  that  the  prompt-response  groups  can  be  entered 
in  any  order. 

Also,  a  command  can  be  cancelled  at  any  time  by  typing  "CAHC" 
as  a  response  or  a  •prompt.  For  example, 

open.carc 

OPEN  ,FXLF;=  CAR  C 


Rote  that  DEF  and  CANC  are  essentially  reserved  vords.  The  user  inter¬ 
face  treats  commas,  blanks,  and  equal  signs  as  interchangeable  separa¬ 
tors.  Also,  multiple  separators  are  treated  as  a  single  separator. 

This  means  that  the  commas  in  the  previous  examples  could  he  replaced  by  ! 

any  combination  of  one  or  more  blanks  and  commas.  The  same  is  true  of  | 

the  equal  signs,  hut  their  use  is  recommended  to  make  the  comma  lines  t 

easy  to  read.  The  slashes  are  required  separators  between  prompt-response  | 

groups,  but  they  can  be  preceded  or  followed  by  blanks  or  commas.  j 

A  response  may  include  separators  (i.e.,  commas,  blanks,  equal  ; 

signs,  and  slashes)  if  it  is  enclosed  in  quote  mark*  (n).  For  example,  , 

on  some  computers  file  names  contain  embedded  blanks,  e.g.,  ! 

OPEN  FILE=  "MOPAES  DBF"  | 

Without  the  quote  marks  above,  MOPAES  will  consider  MOPAES  DBF  as  two 

responses  when  only  one  is  desired.  (ROTE:  A  single  prompt  may  have  \ 

more  than  one  response  if  the  programmer  specified  it  that  way.  In 

such  a  case,  each  response  would  be  separated  by  &  blank  or  comma.  In 

the  case  above,  however,  where  a  single  response  is  required,  the  quote 

marks  must  he  used  to  embed  the  blank  in  the  response.) 

Any  response  may  he  enclosed  in  quotes,  although  there  is  no  > 

advantage  in  doing  so  unless  a  separator  is  to  be  embedded.  Blank 
responses  can  be  entered  with  "  •"  where  at  least  one  blank  appears 
between  the  quotes. 

A  generalization  of  entering  only  some  of  the  prompts  is  to 
enter  only  the  command  name: 

OPEN 

IS  IWOEEIRO  ]  =EEF 

FILE (HO  DEFAULT)  =MOPALS. DBF 

STiuUS  [OLD]=EE? 
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The  User  Interface  vill  prompt  for  all  responses.  This  method  can  "be 
selected  if  the  user  does  not  remember  the  prompts. 

For  commands  which  the  user  issues  frequently,  a  concise  mode 
can  he  selected  hy  preceding  the  command  with  "C-j".  In  this  case, 
the  prompt*  part  of  the  syntax  may  be  omitted.  For  example. 


C-OFEN  DEF/MOPADS . DBF 


Responses  must  be  entered  in  the  same  order  as  they  are  prompted  in 
the  comman d-naxar-only  form.  He  response  may  be  shipped,  except  that 
if  all  remaining  responses  have  defaults  and  the  defaults  are  desired, 
then  the  command  line  may  be  terminated  (e.g.,  the  STATUS  response 
was  omitted  above  since  OLD  was  desired) .  The  daish  works  in  the 
concise  mode  in  the  same  way  as  in  other  modes. 


The  following  rules  vill  formalize  the  previous  discussion  of  how 
syntax  is  processed  by  FFSP.  j 

The  cornmand-n  oie-only  form  of  a  command  may  be  used  at  any  time 


by  typing  only  the  command  name. 


Blank  responses  and  responses  containing  separators  may  be  entered 
by  enclosing  them  in  quotes.  To  enter  a  blank  response  type 
"  "  (including  the  quotes).  At  least  one  blank  must  be  entered  between 
the  quote  marks. 


A  command  may  be  cancelled  at  any  time  by  typing  CA1IC  for  any 
prompt  or  response.  You  can  not  abbreviate  CANC. 


The  user  may  elect  to  use  the  default  value(s)  by  typing  DEP  for 
any  response  in  a  response  Tii.^  up  to  one  field  past  the  last  response 
in  the  list.  * 

Slashes  (/)  must  be  used  to  separate  one  prompt-response  group 
from  another.  Blanks  or  commas  may  be  used  to  separate  all.  other  fields. 
The  equal  sign  should  be  used  to  separate  prompts  from  their  responses; 
however,  it  is  not  Required. 

Command  and  prompt  names  may  be  abbreviated  to  any  non-ambiguous 
string  of  characters.  .  For  example,  if  there  are  two  commands,  DESIGH 
and  DESCRIBE,  they  can  he  abbreviated  DESI  and  DESC  respectively.  The 
commands  may  be  abbreviated  in  longer  forms.  For  example,  the  user  may 
enter  DESC,  DESCR,  DESCRI,  DESCRIB,  or  DESCFJBE  for  the  command  DESCRIBE^ 


* 

jt 


If  a  command  line  in  regular  or  concise  mode  is  ended  with  more 
than  one  dash,  the  last  dash  will  signify  to  the  system  to  prompt  the  | 

user  for  all  the  unentered  responses.  Other  dashes  vill  then  be  con-  !' 

sidered  as  part  of  a  response.  :  J 
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Any  multiple  combination  of  commas  anl  'o' larks  is  treated  as  a 
single  separator.  For  example, 

NAME  «  BILL  WOL?  and  NAME  *  BILL  ,  WOLF 


are  equivalent  (here  the  response  is  a  list  of  two  character  strings). 

If  the  user  enters  an  incorrect  response  or  misuses  the  syntax, 
FFSP  vill  explain  the  error  and  prompt  interactively  for  all  remaining 
respons  es . 

Concise  mode  is  signified  by  preceding  the  command  name  vith  "C-" 
(vithout  the  quotes). 

1-3.  The  Current  Directory  and  Current  Data  List. 


MOPADS  data  bases  are  made  up  of  multiple  directories, 
each  of  vhich  may  ovn  one  or  more  directories  and  data  lists.  Normally, 
the  User  Interface  operates  on  one  directory  vhich  is  designated 
"current."  Similarly,  one  data  list  cf  the  current  directory  can  he 
designated  the  current  data  list.  This  ensures  that  the  action  of  User 
Interface  commands  are  unambiguous.  Facilities  are  provided  for  deter¬ 
mining  the  current  LB  and  LL  and  for  selecting  a  LB  and  LL  to  become 
current.  Note  that  same  commands  automatically  change  the  current  LB 
and  LL. 


2-0  BASIC  LATA  BASE  COMMANDS. 

2—1.  CLOSE. 

The  CLOSE  command  (Figure  A-2)  vill  close  either  the  vorhing 
or  reference  data  base.  I«.  can  be  used  to  svitch  to  a  new  data  base  fil 

2-2.  CURRENT. 

The  CURRENT  command  (Figure  A-3)  vill  display  label,  ID 
or  both  of  the  current  directory  and/or  data  list  on  either  data  base. 

2-3.  DEPOSIT. 

DEPOSIT  (Figure  A-U)  is  a  lov  level  editing  command  that 
allovs  any  element  of  the  ciirrent  data  list  to  be  changed.  DEPOSIT 
interactively  requests  element  numbers  and  nev  values. 

2-U.  DIRECTORY. 


DIRECTORY  (Figure  A-5)  shovs  the  contents  (all  earned  direc¬ 
tories  and/or  data  lists)  of  the  current  directory  an  either  data  base. 
T>.  shovs  the  labels,  ID's,  and  directory  positions  of  the  contents. 

This  information  is  useful  for  the  SELECT  command. 
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Figure  A-2.  CLOSE  Conunand  Specifications 
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Figure  A-3*  CURRENT  Cootmand  Specification* 
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Figure  A-1*.  DEPOSIT  Command  Specification* 
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Figure  A-5.  DIRECTOitf  Comcuid  Spec!  fleet  ions 


2-5.  EXAMINE. 


EXAMINE  (Figure  .\~6)  vill  display  selected  contents  of 
the  current  data  list  to  the  terminal  or  to  the  MOPADS  line  printer 
output  file.  If  the  latter  is  selected,  the  data  list  label  and 
other  information  vill  also  he  printed. 

2-6.  HELP. 

HELP  (Fig-ire  A-T)  vill  print  the  prompts  and  options  for 
the  prompts  for  the  specified  command. 

2-T.  MENU. 

MENU  has  no  prompts.  It  vill  print  all  commands  available 
in  the  current  subprocess. 

2-8.  OPEN. 


OPEN  (Figure  A-8)  vill  crpen  a  data  base  file  as  either  the 
vorking  or  reference  ED.  OPEN  vill  not  automatically  close  the  current 
IB.  CLOSE  must  he  used  explicitly  before  0 PEI  to  switch  DB  files. 
MAXFECOHD  is  the  maximum  number  of  records  allowed  in  a  data  base  file. 
It  may  not  he  needed  for  your  computer.  Zero  implies  no  limit  an  the 
file  size.  The  (MASTER-DIRECTOR! )  is  current  after  the  OPEH  command. 

2-9.  PLINK. 

PL  INK  (Figure  A-9)  vill  change  the  current  directory  to 
tne  owner  of  the  directory  which  was  current  when  PLINK  was  issued. 

2-10.  QUIT. 

QUIT  has  no  prompts.  It  causes  the  current  suhprocess  to 

he  exited. 

2-11.  SELECT. 

SHECT  (Figure  A-10)  changes  the  current  directory  or  data 
list  to  one  that  is  owned  by  the  directory  that  is  current  vhen  SELECT 
is  issued.  The  desired  DR  or  DL  is  eelected  by  specifying  one  (and  only 
one)  of  the  following:  1  -  its  directory  position,  2  -  its  label,  or 
3  -  its  ID.  This  information  is  obtained  vith  the  DIRECTOR!  command. 

2-12.  TERMINATE. 

TERMINATE  has  no  prompts.  It  vill  close  all  open  data  bases 
and  termiante  execution.  This  is  the  normal  way  to  end  a  User  Interface 
session. 
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Figure  A-6.  EXAMINE  Conaand  Specifications 
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Figure  A-7«  HELP  Commund  Specifications 
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Figure  A-8.  OPEN  Cocmond  Specifications. 


COMMAND  DATA  SPECIFICATION 
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Figure  A-9.  PLIHK  Command  Specifications 


I 


I 


I 


o 

■>« 

s 

V 


•H 

Cm 


85 


tenter  only  one  of  the  above  three) 
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3-0  USER  INSTRUCTIONS  AND  EXAMPLES. 

Figure  A-ll  is  an  example  using  all  of  the  Basic  Da'-a  Base 
Gasman  us.  The  annotations  are  explained  belovr. 
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The  CLOSE  commands  disassociates  the  current 
data  base  file  from  the  MOPADS  software.  After 
close,  MOPADS  vill  know  no  working  I®.  If  STATUS 
is  specified  as  DELETE,  the  data  base  file  will  be 
destroyed  permanently. 

OPES  associates  the  data  base  file  VOLfcfi.EBF 
to  the  software  as  the  working  DB.  STATUS=OLD 
implies  that  the  DBF  was  previously  created  as  a 
MOPADS  data  base  file.  If  STATUS=NEW  is  specified, 
MOPADS  will  create  a  new  MOPADS  DB  on  VOL^.DBF, 
and  any  information  previously  contained  on  VOIliS.DBF 
vill  be  lost. 

The  METIU  command  is  always  available  to  list  the 
commands  currently  available. 

HELP  prints  information  about  a  particular  command. 

The  user  has  asked  for  information  on  the  prompts 
DISPLAY  and  TYPE.  For  DISPLAY,  MOPADS  shows  that 
it  expects  a  response  of  one  character  string  that 
must  be  one  of  the  enumerated  values  LABEL  (display 
the  label),  ID  (display  the  ID),  or  ALL  (display  both 
label  and  ID).  The  default  is  LABEL.  HELP  is 
terminated  by  entering 

When  OPEN  is  issued,  the  (MASTER-DIRECTORY)  becomes 
current.  The  CURRENT  command  will  not  display  a 
directory  which  has  no  owner,  which  of  course,  the 
MASTER-DIRECTORY  does  not. 

The  DIRECTORY  command  vill  always  work,  however,  even 
on  the  (MASTER-DIRECTORY).  The  contents  of  the  (MASTER- 
DIRECTORY)  are  shown. 

The  SELECT  command  makes  the  REFERENCE-ADSM  directory 
current  by  specifying  its  directory  position  in  the 
(MASTER -DIRECTORY) . 

The  DIRECTORY  command  confirms  that  REFERENCE-ADSM 
is  current  and  shows  the  owned  reference  ADSM’s  (in 
this  case  only  one,  E- EXAMPLE). 
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Figure  A-U.  Example  Using  Basic  Ccmmands. 
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Figure  A-ll.  (continued) 
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Figure  A-ll.  (continued) 
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Select  E-EXAMPLE  to  be  current. 

Look  at  tbe  data  list  directory  of  E-EXAMFLE. 

This  operator  state  vector  will  be  edited. 

Tbe  SELECT  command  makes  the  above  operator  state 
vector  the  current  data  list.  This  is  confirmed 
with  the  following  CURRENT  c remand. 

EXAMINE  specifies  that  the  data  list  is  to  be  dis¬ 
played  at  the  terminal.  The  user  wants  ro.r  2. 
EEADEF*Y  causes  the  "BATA  LIST  REPORT"  and  the 
next  6  lines  to  be  printed. 

This  display  demonstrates  that  the  basic  data  base 
commands  are  low  level  commands;  they  know  nothing 
about  the  structure  or  contents  of  MOPADS  data  bases. 
The  operator  state  vectors  have  two  rows.  The 
second  row  contains  the  reference  values  for  each 
column.  Prior  to  a  simulation,  the  second  row  is 
copied  to  the  first  row,  which  is  dynamically 
accessed  during  the  simulation.  In  this  vay,  the 
reference  or  starting  values  are  not  lost.  MOPADS 
stores  column  labels  only  for  the  first  row,  however, 
since  it  vculd  double  the  storage  requirement  to 
duplicate  the  labels  for  each  row.  The  "CREATE/EDIT 
REFERENCE  SYSTDi  MODULE"  subprocess  knows  all  of 
this,  so  when  &  listing  is  obtained  with  the  CHARGE 
command  in  that  subprocess,  the  labels  appear  with 
the  reference  values. 

The  EXAMINE  command,  however,  simply  operates  on  a 
data  list  without  knowledge  of  the  meaning  of  its 
contents.  Here,  all  of  the  elements  of  row  2  appear 
to  be  (UIJLABELED) .  Also,  EXAMINE  prints  the  entire 
row.  Only  a  portion  of  the  listing  is  shown  here 
for  brevity. 

Use  the  DEPOSIT  command  to  change  elements.  It  too 
is  a  low  level  command,  so  {row,  column)  addressing 
must  he  used. 

Elements  17,  18,  and  19  of  row  2  are  changed  (these 
are  operator  trace  parameters). 

This  demonstrates  MOPADS  response  to  input  errors. 
The  DEPOSIT  command  had  not  yet  terminated  when  the 
user  entered  tbe  next  EXAMINE.  MOPADS  is  expectirg 
a  numeric  value  for  a  row  number.  The  free-format 
Input  processor  examines  every  input  string  for  * 


r-92 


1-93 


APPENDIX  J 

MOPADS  FINAL  REPORT: 
CREATING  MOPADS  AIR  SCENARIOS 


TABLE  OF  CONTENTS 


List  of  Figures . .  , .  vii 

List  of  Tables . Tii 

Terminology .  Till 

Section  Page 

I  INTRODUCTION . 1-1 

1- 0  Purpose .  1-1 

2- 0  Information  Needed. . . .  1-1 

II  COMMANDS  AVAILABLE .  II-l 

1- 0  Basic  Data  Base  Commands .  II -1 

2- 0  The  ADD-AIR  Command .  II-l 

3- 0  The  ADD- ASSETS  Command .  II-5 

L-0  The  DELETE  Command . II- 5 

5- 0  The  GET  Command .  H-5 

6- 0  The  RENAME  Command .  II-1G 

7- 0  The  SAVE  Command .  n-10 

III  USER  INSTRUCTIONS  AND  EXAMPLES .  III-l 

1- 0  A  Simple  Example . III-l 

2- 0  The  ADD-ASSETS  and  ADD-AIR  Commands . .  III-l 

3- 0  The  SAVE  and  RENAME  Commands .  III-7 

L-0  Hie  GET  and  DELETE  Commands .  III-8 

IV  REFERENCES .  IV-1 

V  DISTRIBUTION  LIST .  V-l 

VI  CHANGE  NOTICES .  VI-1 

APPENDIX 

A  INTRODUCTION  TO  THE  MOPADS  USER  INTERFACE. .  A-l 

1-0  Conversing  With  the  MOPADS  User 

Interface . .  A-l 


J-l 


TABLE  OF  CONTENTS 

( continued) 


22£« 

1-1.  Organization . A-l 

1-2.  Syntax  Rules .  A-l 

1- 3.  The  Current  Directory  and 

Current  Data  List . .  A- 5 

2- 0  Basic  Data  Base  Commands . .  A- 5 

2- 1.  CLOSE .  A-5 

2-2.  CURRENT .  A-5 

2-3.  DEPOSIT .  A-5 

2-k.  DIRECTORY .  A-5 

2-5.  EXAMINE .  A-10 

2-6.  HELP .  A-10 

2-7.  MENU .  A-10 

2-8.  OPEN .  A-10 

2-S.  PLINK .  A-10 

2-10.  QUIT . A-10 

2-11.  SELECT .  A-10 

2-12.  TERMINATE .  A-10 

3- 0  User  Instructions  and  Examples .  A-l6 


J-2 


LIST  OF  FIGURES 


Figure  Page 

1-1  Scenarios  Portion  of  the  MOPADS  Data  Bsse .  1-2 

III-l  Example  Terminal  Session .  III-3 

LIST  OF  TABLES 

Table  Page 

1-1  Contents  of  the  COORDINATE-AND-ASSET-DATA 

Data  List . 1-3 

I- 2  Contents  of  AIRCRAFT-TRACKS  Data  Lists .  1-5 

II- l  The  ADD-AIR  Command . . .  II-2 

II-2  Track  Data  File  Format . . .  11-3 

II-3  Track  Data  File  Layout . II-L 

II-L  The  ADD-ASSET  Command .  II-6 

II-5  The  ASSETS  Data  File  Format .  II-7 

II-6  The  DELETE  Command . II-8 

II-7  The  GET  Command. . .  II-9 

II-8  The  RENAME  Command .  11-11 

II- 9  The  SAVE  Command .  11-12 

III- l  Simple  Asset  Configuration .  III-l 

III-2  Sample  Track  Data  File .  III-2 


J-3 


TERMINOLOGY 


1-0  STANDARD  MOPADS  TERMINOLOGY. 


AIR  DEFENCE  SYSTEM  A  component  of  Air  Defense  which  includes 

equipment  and  operators  and  for  which  techni¬ 
cal  and  tactical  training  are  required. 
Examples  are  IHAWK  and  the  AN/TSQ-73. 


AIR  DEFENSE  SYSTEM  Models  of  operator  actions  and  equipment 
MODULE  characteristics  for  Air  Defense  Systems  in 

the  MOPADS  software.  These  models  are  pre¬ 
pared  with  the  SAINT  simulation  language. 

Air  Defense  System  Modules  include  the  SAINT 
model  and  all  data  needed  to  completely 
define  task  element  time,  task  sequencing 
requirements,  and  human  factors  influences. 


AIR  SCENARIO  A  spatial  and  temporal  record  of  aerial 

activities  and  characteristics  of  an  air 
defense  battle.  The  Air  Scenario  includes 
aircraft  tracks,  safe  corridors,  ECM,  and 
other  aircraft  and  airspace  data.  See  also 
Tactical  Scenario. 


BRANCHING  A  term  used  in  the  SAINT  simulation  language 

to  mean  the  process  by  which  TASK  nodes  are 
sequenced.  At  the  completion  of  the  simulated 
activity  at  a  TASK  node,  the  Branching  from 
that  node  determines  which  TASK  nodes  will  he 
simulated  next. 


DATA  BASE  CONTROL  That  part  of  the  MOPADS  software  which  performs 

SYSTEM  all  direct  communication  with  the  MOPADS  Data 

Base.  All  information  transfer  to  and  from 
the  data  base  is  performed  by  invoking  the  sub¬ 
programs  whir.h  make  up  the  Data  Base  Control 
System. 


DATA  SOURCE  A  specialist  in  obtaining  and  interpreting 

SPECIALIST  Army  documentation  and  other  data  needed  to 

prepare  Air  Defense  System  Modules. 


ENVIRONMENTAL  An  element  of  an  Environmental  State  Vector. 

STATE  VARIABLE 
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ENVIRONMENTAL 
STATE  VECTOR 


An  array  of  values  representing  conditions  or 
characteristics  that  may  affect  more  than  one 
operator.  Elements  of  Environmental  State 
Vectors  my  change  dynamically  during  a  MOPADS 
simulation  to  represent  changes  in  the  environ¬ 
ment  conditions. 

MODERATOR  FUNCTION  A  matberatical/logical  relationship  vhich 

altera  jhe  nominal  time  to  perform  an  operator 
aetivit/  (usually  a  Task  Element).  The  nominal 
time  is  changed  to  represent  the  operator's 
capability  to  perform  the  activity  based  on  the 
Operator's  State  Vector. 

KOPADS  DATA  i>ASE  A  computerized  data  base  designed  specifically 

to  support  the  MOPADS  software.  The  MOPADS 
i  Data  Ease  contains  Simulation  Data  Set(s).  It 

communicates  interactively  with  MOPADS  Users 
during  pre-  and  post-run  data  specification  and 
,  dynamically  with  the  SAINT  software  during 

I  simulation. 

MCPADS  MODELER  An  analyst  who  will  develop  Air  Defense  System 

Modules  and  modify/develop  the  MOPADS  software 
system. 

MOPADS  USER  An  analyst  who  will  design  and  conduct  simu¬ 

lation  experiments  with  the  MOPAIS  software. 

MSAINT(MOPADS/SAINT)  The  variant  of  SAINT  used  in  the  MOPADS  system. 

The  standard  version  of  SAINT  has  been  modified 
t  for  MOPADS  to  permit  shareable  subnetworks  and 

more  sophisticated  interrupts.  The  terms  SAINT 
and  MSAHJT  are  used  interchangeably  when  no 
confusion  will  result.  See  a>.so,  SAINT. 

i 

OPERATOR  STATE  One  element  of  an  Operator  State  Vector. 

VARIABLE 

An  array  of  values  representing  the  condition 
and  characteristics  of  an  operator  of  an  Air 
Defense  System.  Many  values  of  the  Operator 
State  Vector  will  change  dynamically  during 
the  course  of  a  MOPADS  simulation  to  represent 
changes  in  operator  condition. 


OPERATOR  STATE 
VECTOR 


OPERATOR  TASK 

An  operator  activity  identified  during 
veapca*  system  front-end  analyses. 

SAINT 

The  underlying  computer  simulation  language 
used  to  model  Air  Defense  Systems  in  Air 

Defense  System  Modules.  SAINT  is  an  acronym 
for  Systems  Analysis  of  Integrated  Networks  of 

Tasks.  It  is  a  veil  documented  language  designed 
specifically  to  represent  human  factors  aspects 
of  man /machine  systems.  See  also  MSAUST. 

SIMULATION  DATA  SET 

The  Tactical  Scenario  plus  all  required  sirnu-  j 
lation  initialization  and  other  experimental  j 
data  needed  to  perform  a  MOPADS  simulation. 

SIMULATION  STATE 

j 

At  any  instant  in  time  of  a  MOPADS  simulation  > 

the  Simulation  State  is  the  set  of  values  of  all  i 

variables  in  the  MOPADS  software  and  the  MOPADS 

Data  Base.  \ 

SYSTEM  MODULES 

See  Air  Defense  System  Modules. 

TACTICAL  SCENARIO 

The  Air  Scenario  plus  specification  of  critical 
assets  end  the  air  defense  configuration  > 

(number,  type  and  location  of  weapons  and  the  | 

command  and  control  system). 

TACTICAL  SCENARIO 
COMPONENT 

; 

An  element  of  a  Tactical  Scenario j  e.g.,  if  a 

Tactical  Scenario  contains  several  Q-73's,  each  j 

one  is  a  Tactical  Scenario  Component.  ; 

TASK 

See  Operator  Task. 

TASK  ELEMENTS 

Individual  operator  actions  vhich,  when  grouped 
appropriately,  make  up  operator  tasks.  Task 
elements  are  usually  represented  by  single 

SAINT  TASK  nodes  in  Air  Defense  System  Modules. 
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TASK  NODE  A  modeling  symbol  used  in  the  SAINT  simu¬ 

lation  language.  A  TASK  node  represents 
an  activity;  depending  upon  the  modeling 
circumstances ,  a  TASK  node  may  represent 
an  individual  activity  such  as  a  Task 
Element,  or  it  may  represent  an  aggregated 
activity  such  as  an  entire  Operator  Task. 


TASK  SEQUENCING  A  mathematical/logical  relationship  vhich 

MODERATOR  FUNCTION  selects  the  next  Operator  Task  vhich  an 

operator  will  perform.  The  selection  is 
based  upon  operator  goal  seeking 
characteristics. 


2-0  OTHER  TERMINOLOGY. 


ACC 

ADSM  Code  Character. 

ADSM 

Air  Defense  System  Module. 

DATA  BASE 

The  collection  of  user  information  and 
control  information  that  is  processed  by 
the  DBCS. 

DATA  BASE  FILE 

A  computer  file  stored  on  disk  that 
contains  the  data  base. 

DATA  LIST 

A  list  of  values  (character  or  numeric) 
that  is  user  specified  and  is  stored  in  . 
a  data  base. 

DB 

Data  Base. 

DBCS 

Data  Base  Control  System. 

DBF 

Data  Base  File. 
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DIRECTORY 

A  collection  of  data  lists  and  other 
directories. 

DL 

Data  List. 

DR 

Directory. 

ID 

Identify.  DL's  and  DR's  have  identifiers 
that  are  lists  of  integers  and  are  stored 

- 

in  their  owning  directory. 
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INTRODUCTION 


1- 0  PURPOSE. 

This  document  describes  the  facilities  available  in  the  MOPADS 
User  Interface  for  creating  and  editing  Critical  Asset  Configurations 
and  Air  Scenarios.  These  aspects  of  MOPADS  models  describe  the 
assets  to  be  protected  by  the  air  defense  system  and  the  flight 
paths  of  aircraft  that  interact  vith  it. 

The  User  Interface  provides  a  mechanism  to  create  and  modify 
descriptions  of  critical  assets  and  air  scenarios.  Asset  and  track 
descriptions  are  prepared  on  external  data  files.  The  user  interface 
has  commands  which  will  read  the  data  files  and  create  the  appropriate 
entries  in  the  MOPADS  data  base.  These  entries  can  then  be  edited  if 
needed. 

2- 0  INFORMATION  NEEDED. 

A  schematic  of  the  section  of  the  MOPADS  data  base  that  concerns 
air  scenarios  is  shown  in  Figure  1-1.  (A  More  detailed  description  of 
the  MOPADS  data  base  is  contained  in  Polito,  Vol.  5.17.)  There  is  one 
directory  labeled  "SCENARIOS"  (code  k)  that  belongs  to  the  master 
directory.  It  owns  all  scenario  information.  Scenarios  are  defined 
which  consist  of  critical  asset  configurations  and  one  or  more  air 
scenarios  that  interact  with  it.  Thus,  the  "CRmCAL-ASSET-CONFIGURA- 
TION"  directories  (code  13)  own  »  data  list  that  contains  the  coordi¬ 
nates  of  critical  assets  ( "COORD INAXE-AND-ASSET -DATA") .  More  than  one 
"CRTnCAL-ASSET-CONFIGURATION"  directory  may  be  present.  They  all  have 
the  same  label,  and  are  distinguished  by  user  assigned  numbers  (e.g., 

1,  2,  3,  etc.). 

Each  "CRITICAL- ASSET-CONFIGURATION"  may  contain  one  or  more  air 
scenario  directories  (code  8).  Each  air  scenario  directory  will 
have  a  unique,  user  assigned  label  (signified  by  lower  case  letters  in 
the  code  8  boxes  in  Figure  I— 1 ) .  The  air  scenarios  may  contain  three 
data  lists  for  hostile,  friendly,  and  other  tracks. 

When  performing  a  MOPADS  simulation,  the  MOPADS  user  will  select 
the  CRITICAL-ASSET-CONFIGURATION  and  the  air  scenario  to  simulate.  The 
MOPADS  software  will  then  access  the  data  from  the  appropriate  data  base 
entries. 

The  contents  of  the  " COORDINATE- AND-ASSET-DATA"  data  list  are 
shown  in  Table  1-1.  In  order  to  create  a  CRITICAL-ASSEr-CONFIGURATION , 
the  MOPADS  analyst  must  determine  the  location  of  each  asset.  The 
coordinates  are  given  in  relation  to  a  reference  position  that  is 
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Figure  1-1.  Scenarios  Portion  of  the  MOPADS  Data  Base. 
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specified  in  decimal  degrees  and  feet  above  rean  sea  level;  All  other 
positions  are  specified  in  nautical  miles  (for  z  and  y  coordinates) 
and  feet  (for  the  z  coordinate)  from  this  point.  (MOPADC  assumes  a 
flat  earth.)  Each  site  may  "be  assigned  a  code  (SITE-TYPE)  and  a  five 
character  label.  Critical  assets  are  not  air  defense  urits  that  are 
modeled  in  the  MOPADS  system.  Air  defense  units  are  automatically 
protected.  The  sites  specified  in  a  CRXTIC\L-ASSET-CCNFIGURATIOH 
are  non-air  defense  sites  designated  to  he  protected. 

The  contents  of  the  "AIRCRAFT -TRACKS-?"  data  lists  are  shown 
in  Table  1-2.  Three  such  data  lists  exist:  one  each  for  hostile, 
friendly,  and  other  tracks.  All  three  of  the  data  lists  need  not 
exist.  These  data  lists  have  nine  columns  and  as  many  rows  as  needed. 
One  track  consists  of  two  or  more  rows. 

Aircraft  tracks  are  represented  as  connected  line  segments. 

The  first  row  of  a  track  is  its  initiation  row.  It  specifies  the 
initiation  point  (relative  to  the  coordinate  reference  point;  and  the 
initiation  time  (in  minutes  from  the  start  time  of  the  simulation). 

Also,  the  initiation  rcw  has  an  identifier,  the  actual  primary  ID,  the 
aircraft  type,  and  multiplicity.  Immediately  following  the  initiation 
row  art  one  or  more  segment  rows  which  give  the  end  point  of  the  seg¬ 
ment  and  the  speed  on  the  segment.  For  hostile  tracks,  an  indicator 
gives  whether  the  end  point  of  the  segment  is  a  target  (protected  site) 
and  whether  the  aircraft  is  jamming  on  the  segment.  The  segment  rows 
are  in  their  correct  geographical  order.  Each  track  is  represented  by 
a  group  of  one  initiation  row  and  one  or  more  segment  rows,  and  the 
groups  of  track  rows  are  ordered  by  track  initiation  time.  In  other 
words,  the  tracks  which  initiate  earliest  are  in  the  lower  numbered  row. 

Developing  a  scenario  is  the  first  and  most  fundamental  task  of 
building  a  MOPADS  simulation,  since  everything  including  the  air  defense 
system  will  be  located  with  reference  to  the  coordinate  reference  point. 
The  MOPADS  analyst  must  assemble  all  of  the  information  in  Tables  1-1 
end  1-2  and  prepare  data  files  described  in  the  next  section  before 
initiating  a  User  Interface  session. 


NOTE 

Aircraft  flight  paths  may  not  terminate  in  radar 
coverages.  The  MOPADS  software  will  generate  an 
error.  Friendly  aircraft  may  be  represented  as 
landing  within  coverage  by  creating  a  final  flight 
segment  with  zero  velocity. 
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II.  COMMANDS  AVAILABLE 


1-0  BASIC  DATA  BASE  COMMANDS. 


The  basic  data  base  commands  that  are  available  in  all  sub¬ 
processes  of  the  User  Interface  are  also  available  in  this  subprocess. 
Descriptions  of  these  commands  are  repeated  in  Appendix  A  for  easy 
reference. 

2-0  THE  ADD-AIR  COMMAND. 

The  ADD-AIR  command  creates  or  modifies  an  air  scenario  direc¬ 
tory  of  the  current  "CRITICAL- ASSET-CONFIGURATION"  on  the  working 
data  base.  The  prompts  are  shewn  in  Table  II-l.  LABEL  is  a  label  for 
the  air  scenario.  FILE  is  an  external  formatted,  sequential  data 
file  which  contains  track  data.  Its  format  is  shown  in  Table  II-2. 

As  can  be  seen  from  Tables  II-2  and  II-3  the  Track  Data  File 
may  contain  tracks  of  all  three  types.  Several  possibilities  exist 
here: 

1.  The  specified  air  scenario  did  not  previously  exist. 

MOPADS  will  read  FILE  and  create  data  lists  for  whichever  track  types 
exist  on  the  file. 

2.  The  specified  air  scenario  previously  existed. 

MOPADS  will  ask  if  information  in  the  air  scenario  may  be  overwritten. 
2a.  The  answer  is  YES. 

MOPADS  will  delete  an  "AIRCRAFT-TRACK"  data  list  and  replace  it  if 
like  kind  tracks  axe  found  on  FILE.  For  example,  an  " AIRCRAFT -TRACKS- 
HOSTILE"  data  list  exists  and  hostile  tracks  are  found  on  FILE,  the 
AIRCRAFT-TRACKS  data  list  will  be  deleted  and  completely  replaced  by 
the  hostile  tracks  on  FILE.  An  existing  "AIRCRAFT-TRACKS"  data  list 
will  not  be  deleted  unless  replacements  are  found  in  FILE. 

2b.  The  answer  is  NO. 

MOPADS  will  skip  tracks  on  FILE  for  which  an  "AIRCRAFT-TRACKS"  data  list 
already  exists.  For  example,  if  AIRCRAFT-TRACKS-HOSTILE  exists  and 
hostile  tracks  are  found  on  FILE,  they  will  be  skipped,  and  the  existing 
data  list  will  not  be  disturbed.  Other  track  types  on  FILE  for  which 
no  "AIRCRAFT -TRACKS"  data  list  exists  will  be  added  to  the  directory  in 
the  normal  manner. 
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Table  II-2.  Track  Data  File  Format 


COLUMNS  DESCRIPTION  FORMAT 


Etisjix  IS  Bsese4 


1-3 

-1 

13 

6-15 

Prinary  IB 

610.3 

(1 -hostile  ,2-friendly  ,'3-other) 

Track  Initiation  Record 

1-3 

0 

13 

6-15 

Track  ID  nunber 

G10.3 

16-23 

Initiation  tine  (ninutes  fron 

810.3 

start  of  sinulation) 

26-35 

Multiplicity 

610.3 

36-45 

Aircraft  type 

610.3 

46-55 

x-position  (n.ai.) 

610.3 

56-65 

y-position  (n.ni.) 

610.3 

66-73 

2-position  (ft.) 

610.3 

T-act  SejnenJ  Record 

1-3 

1 

13 

6-13 

x-position  of  end  of  segnent  (n.ni.) 

610.3 

16-25 

y-position  of  end  of  segnent  (n.ni.) 

610.3 

26-35 

z-position  of  end  of  segnent  (n.ni.) 

610.3 

36-45 

speed  (knots) 

810.3 

46-55 

end  point  a  target 

610.3 

(0  -  no,  1  -  yes) 

36-65 

janning  (0  -  no,  1  -  yes) 

610.3 

66-73 

Probability  of  destroying  target  if 

610.3 

(46-55)  is  1 

|nd  gf  Data  Record 

1-3 

2 

13 
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Table  11-3.  Tr«ick  Data  File  Layout 


Prieary  IB  Record 
Track  Initiation  Record 
Segnent  Record 


one  group  for  each  track,  la 
chronological  order. 


Priiiary  IB  record 


tracks  for  this  primary  ID» 


End  of  Data 


NOTE:  Only  one  group  for  each  prinary  ID  is  permitted. 


The  above  features  allows  entire  classes  of  tracks  to  be 
added  or  replaced  easily  within  an  air  scenario. 

3-0  THE  ADD-ASSETS  COMMAND. 

The  ADD-ASSETS  command  will  create  or  modify  a  "CRITICAL-ASSET- 
C0NFIGURATI0N"  directory  on  the  working  data  base.  The  prompts  arc 
shown. in  Table  II-1+.  IDNUMBER  Is  a  positive  integer  which  will 
identify  the  asset  configuration.  FILE  is  an  external,  formatted, 
sequential  data  file  that  specifies  the  assets  to  be  protected.  It's 
format  is  shown  in  Table  II-5. 

ADD-ASSETS  will  check  to  see  if  an  asset  configuration  with  the 
same  IDNUMBER  already  exists.  If  not,  it  will  create  it  and  read  the 
contents  of  FILE  into  the  "COORDINATE-AND-ASSET-DATA"  data  list.  If 
the  specified  IDNUMBER  does  exist,  MOPADS  will  ask  if  it  can  be  over¬ 
written.  If  not,  the  command  will  be  aborted.  If  so,  the  "C00RDINATE- 
AND-ASSET-DA.TA"  data  list  will  be  evicted  and  completely  replaced  by 
the  contents  cf  FILE.  Any  air  scenario  directories  that  belong  to  the 
asset  configuration  will  not  be  disturbed.  This  allows  different  asset 
configurations  to  be  used  with  the  same  air  scenarios  if  desired. 

U-0  THE  DELETE  COMMAND. 

The  DELETE  command  will  delete  an  air  scenario  or  asset  configu¬ 
ration  from  the  working  or  reference  data  base.  If  an  air  scenario  is 
to  be  deleted,  the  owning  asset  configuration  must  be  current. 

The  prompts  for  the  DELETE  command  request  only  the  data  base 
and  the  type  (asset  configuration  or  air  scenario).  MOPADS  will 
request  the  asset  configuration  number  or  air  scenario  label  inter¬ 
actively.  (See  Table  II-6.) 

If  an  asset  configuration  is  deleted,  all  air  scenarios  which 
belong  to  it  are  also  deleted.  Deleted  entities  cannot  be  recovered. 

5-0  ■  THE  GET  COMMAND. 

The  GET  command  will  copy  an  air  scenario  or  asset  configuration, 
from  the  reference  to  the  working  data  base.  The  prompts  for  GET  are 
shown  in  Table  II-7.  The  single  prompt  is  DR  (for  directory).  It  has 
a  two  part  response:  the  type  of  directory  and  its  identifier.  In  the 
case  of  an  air  scenario,  the  identifier  is  its  label.  For  an  asset 
configuration,  the  identifier  is  its  ID  number.  Thus,  valid  GET  commands 
would  be 


GET  DR=AIR-SCENARI0,AIR1 
GET  DR=ASSETS,2 


3 


9 


Table  II-5.  The  ASSETS  Data  Pile  Format 


COLUMNS 


DESCRIPTION 


FORMAT 


Coordinate  Reljrfn£j  g££or4  (First  Record  ia  File) 


1 

1-3 

REFISK 

AS 

! 

*  4-15 

reference  latitude  (deciaal  degrees) 

G10.3 

16-25 

reference  longitude  (decinal  degrees) 

610.3 

i 

26-35 

reference  altitude  (feet  above  MSL) 

610.3 

a 

a 

1 

Asset  Record*  (As  nany  as  needed) 

1 

* 

• 

1-5 

ASSET 

AS 

• 

6-15 

x-coordinate  (n.ni.) 

610.3 

16-25 

y-coordinate  (n.ni.) 

610.3 

; 

26-35 

z-coordinate  (ft.) 

610.3 

• 

4 

36-45 

site  type 

610.3 

i 

46-55 

site  label 

A10 

56-65 

not  used 

610.3 

En$  S 1  Data  Record  (Last  record  ia  file) 


DONE* 


NOTE:  0  means  a  blank  on  the  data  card. 
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If  a i  air  scenario  is  "being  gotten,  its  owning  asset  con¬ 
figuration  must  "be  current  on  the  reference  DB,  and  the  asset, 
configuration  to  own  it  aa  the  working  DB  arust  he  current  on  the 
working  data  base. 

If  an  asset  configuration  is  gotten,  all  air  scenarios  which 
belong  to  it  are  also  copied  to  the  working  DB.  GET  copies  with 
replacement,  so  if  the  specified  air  scenario  or  asset  configuration 
already  exists  on  the  working  IS,  MOPADS  will  as  permission  to  over¬ 
write,  and,  if  given,  it  will  replace  the  existing  version  on  the 
working  DB  with  the  version  on  the  reference  EB. 

6- 0  THE  RENAME  COMMAND. 

RENAME  will  change  the  label  of  an  air  scenario  or  the  lid 
number  of  an  asset  configuration  on  the  working  data  base.  The  prompts 
are  shown  in  Table  II-8.  If  an  air  scenario  is  renamed,  its  owning 
asset  configuration  must  be  the  current  directory. 

7- 0  THE  SAVE  COMMAND. 

I 

*  l 

The  SAVE  command  is  shown;  in  Table  II-9.  It  is  analogous  in 
every  way  to  the  GET  command  except  it  copies  air  scenerios  and  asset 
configurations  from  the  working  to  the  reference  data  base. 
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III.  USER  INSTRUCTIONS  AND  EXAMPLES 


1-0  A  SIMPLE  EXAMPLE. 

Table  III-l  shows  a  sample  data  file  containing  three  sites 
for  a  Critical  Asset  Configuration.  This  file  is  in  the  format  given 
in  Table  II-5.  Similarly,  Table  III-2  is  a  simple  example  of  a  Track 
data  file  in  the  format  explained  in  Tables  II-2  and  XI-3.  Table  III-2 
contains  one  hostile  track,  two  friendly  tracks,  and  one  "other"  track. 

The  data  in  Tables  III-l  and  III-2  is  hypothetical  and  will  be 
used  only  to  demonstrate  the  use  of  the  commands  for  this  subprocess. 

Figure  III-l  is  a  sample  terminal  session  with  tv.»  Create/Edit 
Scenario  Data  subprocess.  Information  entered  by  the  user  has  been 
enclosed  in  boxes  for  emphasis.  The  annotations  are  eaqplaincd  in 
the  sections  that  follow. 


Table  III-l.  Simple  Asset  Configuration. 


REF 

30.2 

-20.5 

103. 

ASSET 

10.5 

12.2 

200. 

2. 

SITE1 

ASSET 

-2.3 

13. 

-2. 

2. 

S1TE2 

ASSET 

DONE 

0 

0 

0 

3. 

SITES 

2-0  THE  ADD-ASSETS  AND  ADD- AIR  COMMANDS. 


The  Create/Edit  Scenario  Data  subprocess  is  entered 
by  selecting  option  from  the  subprocess  option  menu. 
The  prompt  in  this  subprocess  is 


" - ENTER  CR/ED  SCENARIO  COMMAND" 

Upon  entering  this  subprocess  the  "SCENARIOS” 
directory  is  current. 
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fUJCCT  OPTION 


Figure  III-! 


>  x  * 


USE*  HEtSASC: 
DATA  IAS 


[(TBIT  REPORT 


HOPADS  CURRENT  DIRECTORY 

8-  .  .  -  REPERENCE 

ATA  1ASE  FI> ET 1  REP  >  DIP 
IRECToSy  LAiiLt  «HASTEN-DIRECT0RY> 

RANK  I  NO  CODE  <  OWNED  DIRECTORIES) •  INCREASING  ON  I9(  0> 
RAHKINO  CODE ( OWNED  SATA  LISTS):  INCREAS1NO  ON  ID(  0> 


OWNED  DIRECTORIES! 
DIRECTORY  POSITION: 
1-  2>- 


DIRECTORY  POSITION! 

label:  ; 

lb:  <  !•  2)» 


REPERENCE-ADBH 

2  l 


SL  NARIOS 
4  0 


rCTT-Irf^n  CR/ED  SCENARIO  COHNANB 

E5SZSZSSSZE53  !  — — 


HTER  CR/ED  SCENARIO  COHNANB 
P-PEfAuTl  NO-DEFAUL . )« 

“Tone 


I 


s^gg^g^mjj523gS?»rgAi&fl- 


CR/ED  SCENARIO  COHHANO 


CURRENT  DIRECTORY  LABEL  XB:AXR2. 

— — ENTER  CR/ED  SCENARIO  COHNANB 
CUR  D»-R 

CURRENT  DIRECTORT  LABEL  XStAZRl 

, - ENTER  CR/ED  SCENARIO  COHP.AND 

ILkt^T-.T.ia  — g  -  ... 

- ENTER  CR/ED  SCENARIO  COHHANO 


© 


CURRENT.  DIRECTORT  LABEL  XSICRITICAL-ASSET-CONPIOURATZON 
ENTER  CR/ED  SCENARIO  COHNANB 
O-^EPaULT  NO-DEPAULT3*  ,  m.  . - 


- - ENTER  CR/ED  SCENARIO  COHHANO 


CURRENT  DIRECTORT  LAIEL  XS:AIR2 

-—-ENTER  CR/ED  SCENARIO  COHHAND 

— - 

—  —  INTER  CR/ED  BCEHATID  COHHANO 

X2IOif,fe> 


.  (continued) 

I 
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Figure  III-; 


DIRECTORY  UNIT 


UStlt  MESSAGES 
DATA  DASEt 

8  AT  A  SASE  FILE! 

IRECTORY  LABELS 
DIRECTORY  IT'S 


MORASS  CURRENT  DIRECTORY 

REFERENCE 

REF .DBF 

CRITICAL -ASSET-CONFIGURATION 
13  1 


RANKINS  CODE ( OWNED  DIRECTORIES)! 
RANKING  CODESOWnED  DATA  LISTS)! 


INCREASING  ON  ID! 
INCREASING  ON  ID! 


I) 

O) 


OWNED  DIRECTORIES i 
directort’fositions 

LABELS 

IDS  t  1-  2>» 

DIRECTORY  FOSITXON! 

io*Er‘  i-  2>- 


AIR1 


3 

AIR2. 


ER  CR/ED  SCENARIO  COMMAND 

K1!GJ»  "”•*“*  . . .  ' 

CN0-DEFAULT3- 

CURRENT  DIRECTORY  M'JL*T  BE  AN  ASSET  CONFIG. 
SET  CURRENT  DIRECTORY  AND  TRY  AGAIN 


rrrCTScf 


R/ED  SCENARIO  COMMAND 


-© 


—-CMT^CR/E^  SCENARIO  COMMAND 
SCENARIO  TO1" DELETE 


# 


ONE 

NTER  CR/CD  SCENARIO 


COHMANt 


DIRECTORY  RCFORT 
USER  MESSAGES  HOPADS  CURRENY  DIRECTORY 

B2ta  kipfile,  sSlr;i%f 

DIRECTORY  LABELS  critical-asset-confiouration 
DIRECTORY  id:  13  1 

RANKINS  C5PE(DUNE»  DIRECTORIES) S  INCREASINO  ON  ID!  2) 
RANKINO  COSE (OWNED  DATA  LISTS):  INCREASING  ON  ID!  5) 


OWNED  DIRECTORIES! 

NO  DIRECTORIES 

OWNED  D4TA_LIST1J 

DIRECTORY  POSITIONS 
LABELS 

IDS  i  1-  2>»  304 


COORDINATE-AND-ASSET-DATA 

1 


J^j-ENTER  CR/CD  SCENARIO  COI 

^gM^yFAiO~i MO~bgf auLT3» 

-—ENTER  CR/ED  SCENARIO  COMMAND 

sn5E  DH«a 

- ENTER  CR/ED  SCENARIO  COMMAND 

ilua  , :  ,vu 


.  (continued) 
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This  command  specifies  that  a  new  CRITICAL-ASSET- 
CONFIGURATION  directory  is  to  he  created  with  ID 
equal  to  1.  The  asset  data  is  ci  file  SITES. DAT 
(which  is  the  file  shown  in  Table  III-l). 

The  new  asset  configuration  is  current  after  the 
ADD-ASSET  command.  The  IDNUMBER  of  1  has  become 
the  second  word  of  the  directory  ID.  (The  first 
word  is  the  director  code.) 

The  ADD- AID  command  adds  a  new  air  scenario  direc¬ 
tory  (vith  label  AIRl)  to  the  newly  created  asset 
configuration.  The  track  data  is  read  from  the 
file  TRACKS.DAT  (which  is  shown  in  Table  III-2). 

The  new  air  scenario,  AIRl,  is  examined  with  the 
DIRECTORY  command  and  the  three  track  data  lists 
axe  present.  The  contents  could  be  examined 
with  the  EXAMINE  command.  Note  that  the  new  air 
scenario  is  cum  after  the  ADD-AIR  command. 


3-0  THE  SAVE  AND  RENAME  COMMANDS. 


A  Reference  data  base  has  been  opened  (not  shown) 
and  the  DIRECTORY  command  shows  that  the  "(MASTER- 
DIRECTORY)"  is  current. 


The  SELECT  command  is  used  to  make  the  "SCENARIOS" 
directory  current  on  the  reference  DB. 


The  SAVE  command  is  used  to  copy  the  asset  configu¬ 
ration  with  ID  of  1  to  the  reference  DB.  This  will 
copy  asset  configuration  1  and  all  of  its  air 
scenario  directories  (in  this  case,  only  AIRl). 


The  RENAME  command  changes  the  label  of  the  air 
scenario  AIRl  to  AIR2  on  the  working  DB.  The 
change  is  confirmed  with  the  CURRENT  command. 
(See  also  (l9jbelow.) 


10)  We  are  going  to  save  the  air  scenario  AIR2  to  the 
^  reference  DB.  A  CRITICAL-ASSET- CONFIGURATION  must  be 
current  on  the  reference  DB  in  order  to  do  this. 

The  CURRENT  command  shows  that  an  air  scenario  is 
current,  however. 


The  PLINK  command  makes  the  owner  of  AIRl  on  the 
reference  DB  the  new  current  directory.  This  is 
confirmed  by  the  following  CURRENT  command.  Now 
the  SAVE  command  can  be  issued.  (If  SAVE  had  been 
issued  when  AIR2  was  current  on  the  reference  DB, 
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MOPADS  would  simply  have  responded  vith  an  error 
message.  Ho  harm  would  have  been  done.) 


This  SAVE  compand  copies  an  air  scenario,  AIR2, 
to  the  reference  BB.  AIR2  ‘becomes  current  on  the 
reference  IB. 


FLINK  on  the  reference  BB  to  make  the  asset  con¬ 
figuration  current  again. 

"Both  air  scenarios  are  present  on  the  reference  BB. 


1-0  THE  GET  AUB  DELETE  COMMANDS. 


An  asset  configuration  must  he  current  in  order  to 
delete  an  air  scenario.  This  error  message  explains 
this  fact.  The  following  FLIHK  canmand  accomplishes 
the  required  action. 


The  DELETE  command  deletes  AIR2  from  the  working  BB. 

The  DIRECTORY  command  confirms  that  no  air  scenarios 
remain. 


The  GET  command  copies  the  air  scenario  AIR2  from  the 
reference  to  the  working  BB. 

The  RENAME  command  changes  the  IB  of  "CRITICAL-ASSET- 
CCHTFIGURATION"  1  to  2.  The  IB  change  and  the  presence 
of  AIR2  is  confirmed  by  the  BIRECTORY  command. 

Nov  the  GET  command  is  used  to  copy  asset  configuration 
1  from  the  reference  to  the  working  DB. 

After  using  the  FLINK  command  to  make  the  new  con¬ 
figuration  current,  the  DIRECTORY  command  confirms 
the  presence  of  a*set  configuration  1  with  air 
scenarios  AIR1  and  AIR2. 


I 

I 

\ 

I 


l 

j 
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VI.  CHANGE  NOTICES 


APPENDIX  A.  INTRODUCTION  TO  THE  MOPADS  USER  INTERFACE 


1-0  CONVERSING  WITH  THE  MOPADS  USER  INTERFACE. 

1-1.  Organization. 

The  MOPADS  User  Interface  is  hierarchical  in  structure. 
It  consists  of  five  subprocesses  as  shown  in  Figure  A-l.  Each  of 
the  subprocesses  has  its  own  set  of  capabilities  and  commands  to 
invoke  them.  The  subprocesses  are  described  in  separate  documents. 
In  addition,  a  set  of  Basic  Data  Base  Commands  are  provided  that  are 
available  in  all  subprocesses.  The  main  purpose  of  this  section  is 
to  explain  the  use  of  these  commands. 

1-2.  Syntax  Rules. 


The  User  Interface  is  primarily  a  command  driven  processor 
that  waits  for  the  user  to  issue  instructions.  It  does,  however,  have 
aspects  of  menu  driven  systems  in  that  some  commands  result  in  menus 
being  presented  to  the  user.  Also,  the  command  processor  (FFSP  described 
in  Goodin  and  Polito  (1983)  permits  menu-like  presentations  of 
commands. 


CMM*/CD!1 

SIMM  AT  ION  DATA 

Ml 


IIW 

flMUtATIOrt 

DATA 


EXAMINE 

STATISTIC* 


CAIATI/COIT  CMATF/C01T 

SCENARIO  ACrCACRCI 

DATA  SYSTEM 

WtHJLl 


Figure  A-l.  Organization  of  the  User  Interface. 
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The  regular  mode  for  entering  commands  is  shown  below. 


canmand,praJtptl*responsel/pronpt2=response2/. . . 


The  commands  and  prompts  are  keywords  recognized  by  MOPADS.  The 
responses  are  particular  values  for  the  prompts.  For  example, 
consider  this. 


OPEN ,FILE*MOPADS.DBF/CTATUS=OLD 


OPEN  is  the  command.  FILE  and  STATUS  are  prompts  recognized  by 
MOPADS,  and  MOPADS. DBF  and  OLD  are  values  for  the  prompts. 

Certain  prompts  for  a  command  may  have  default  values  that  will 
be  used  if  the  prompt  is  not  entered.  In  the  example  above,  another 
prompt,  D3,  specifies  which  data  base  is  to  be  associated  vith  the  file. 
Its  default  is  WORKING,  so  by  not  entering  it  on  the  command  line, 
WORKING  is  automatically  selected.  If  the  default  value  is  not  desired, 
then  the  prompt  must  be  explicitly  entered  on  the  command  line. 

If  the  user  fails  to  enter  responses  to  all  required  prompts, 
MOPADS  will  interactively  prcmpt  for  them.  For  example. 


OPEN ,STATUS=OLD 

FILE [NO  DEFAULT]  =  MOPADS. DBF 


After  processing  the  OPEN  command,  MOPADS  found  J-hat  the  required 
prompt,  FILE, wan  not  entered.  It  printed  "FILE [NO  DEFAULT]*"  to 
prompt  the  user  for  a  response.  If  the  last  non-blank  character  on  a 
command  line  is  a  dash  (-),  MOPADS  will  interactively  prompt  for  all 
unentered  prompts,  even  those  with  defaults.  For  example. 


OPEN  .STATUS* OLD  - 
DB  [WORKING]  =  REFERENCE 
FILE [NO  DEFAULT]  *  MOPADS. DBF 


The  dash  caused  "DB  [V'ORETNG]*"  to  be  printed.  The  value  between  the 
brackets  is  the  default  for  the  prompt.  The  default  can  be  selected 
by  typing  "DEF"  as  the  response.  DEF  can  also  be  entered  on  the  command 
line;  e.g. 
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OPEN  ,EB*EEF/STATUS*OLD/FIL&'MOPAI>S  .EBP 


The  above  demonstrates  that  the  prompt-response  groups  can  be  entered 
in  any  order. 

Also,  a  c remand  can  be  cancelled  at  any  time  by  typing.  "CANC" 
as  a  response  or  a  prompt.  For  example. 


OPEN.CANC 

OPm,nLE=CAHC 


Mote  that  DEF  and  CANC  are  essentially  reserved  vords.  The  user  inter¬ 
face  treats  commas,  blanks,  and  equal  signs  as  interchangeable  separa¬ 
tors.  Also,  multiple  separators  are  treated  as  a  single  separator. 

This  means  that  the  commas  in  the  previous  examples  could  be  replaced  by 
any  combination  of  one  or  more  blanks  and  commas.  The  same  is  true  of 
the  equal  signs,  but  their  use  is  recommended  to  make  the  command  lines 
easy  to  read.  The  slashes  are  required  separators  betveen  prompt-response 
groups,  but  they  can  be  preceded  or  followed  by  blanks  or  commas. 

A  response  may  include  separators  (i.e. ,  commas,  blanks,  equal 
sigus,  and  slashes)  if  it  is  enclosed  in  quote  marks  (").  For  example, 
on  some  computers  file  names  contain  embedded  blanks,  e.g., 

OPEN  FILE*"MOPAD&  EBF" 

Without  the  quote  marks  above,  MOPADS  will  consider  M0PAD5  EBF  as  two 
responses  when  only  one  is  desired.  {NOTE:  A  single  prompt  may  have 
more  than  one  response  if  the  programmer  specified  it  that  way.  In 
such  a  case,  each  response  would  be  separated  by  a  blank  or  comma.  In 
the  case  above,  however,  where  a  single  response  is  required,  the  quote 
marks  must  be  used  to  embed  the  blank  in  the  response.) 

Any  response  may  be  enclosed  in  quotes,  although  there  is  no 
advantage  in  doing  so  unless  a  separator  is  to  be  embedded.  Blank 
responses  can  be  entered  with  "  n  where  at  least  one  blank  appears 
between  the  quotes. 

A  generalization  of  entering  only  seme  of  the  prompts  is  to 
enter  only  the  command  neme: 

OPEN 

E3  [WORKING ]=L£F 

FUElNO  DEFAULT]  =MOPADS .DBF 

STATUS  [OLD] =DEF 
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The  User  Interface  vill  prompt  for  all  responses.  This  method  can  he 
selected  If  the  user  does  not  remember  the  prompts. 

For  commands  vhich  the  user  issues  frequently,  a  concise  mode 
can  he  selected  by  preceding  the  command  with  "C-".  In  this  case, 
the  prompt*  part  of  the  syntax  may  he  omitted.  For  example, 


C-OFEN  DEF /MOPADS .DBF 


Responses  must  he  entered  in  the  same  order  as  they  are  prompted  in 
the  ccmmand-name-only  form.  So  response  may  he  skipped,  except  that 
if  all  remaining  responses  have  defaults  and  the  defaults  are  desired, 
then  the  command  line  may  he  terminated  (e.g.,  the  STATUS  response 
was  omitted  above  since  OLD  was  desired).  The  dash  works  in  the 
concise  mode  in  the  same  way  as  in  other  modes. 

I 

The  following  rules  will  formalize  the  previous  discussion  of  how 
syntax  is  processed  by  FFSP. 

*  I  !■' 

The  command-name- only  form  of  a  command  may  he  used  at  any  time 
by  typing  only  the  command  name. 

Blank  responses  and  responses  containing  separators  may  he  entered 
by  enclosing  them  in  quotes.  To  enter  a  blank  response  type 
"  "  (including  the  quotes).  At  least  one  blank  must  he  entered  between 
the  quote  marks. 

A  command  may  he  cancelled  at  any  time  by  typing  CA1JC  for  any 
prompt  or  response.  You  can  not  abbreviate  CAUC. 

The  user  may  elect  to  use  the  default  value(s)  by  typing  DEF  for 
any  response  in  a  response  -list  up  to  one  field  past  the  last  response 
in  the  list. 

Slashes  (/)  must  be  used  to  separate  one  prompt-response  group 
from  another.  Blanks  or  commas  may  be  used  to  separate  all  other  fields. 
The  equal  sign  should  he  used  to  separate  prompts  frcrn  tlheir  responses; 
however,  it  is  not  required.  7  > 

Command  and  prompt  names  may  be  abbreviated  to  any  non-ambiguous 
string  of  characters.  For  example,  if  there  are  two  commands,  DESIGH 
and  DESCRIBE,  they  can  be  abbreviated  DESI  and  DESC  respectively.  The 
commands  may  he  abbreviated  in  longer  forms.  For  example,  the  user  may 
enter  DESC,  DESCR,  DESCRI,  DESCRIB,  or  DESCRIBE  for  the  command  DESCRIBE. 

If  a  command  line  in  regular  or  concise  mode  is  ended  with  more 
than  one  dash,  the  last  dash  vill  signify  to  the  system  to  prompt  the 
user  for  all  the  unentered  responses.  Other  dashes  vill  then  be  con¬ 
sidered  as  part  of  a  response. 
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Any  multiple  combination  of  commas  and  blanks  is  treated  tu  a 
single  separator.  For  example, 

NAME  -  BILL  VOLF  and  NAME  «  BILL  ,  WOLF 


are  equivalent  (here  the  response  is  a  list  of  tvo  character  strings). 

If  the  user  enters  an  incorrect  response  or  misuses  the  syntax, 
FFSP  will  explain  the  error  and  prompt  interactively  for  all  remaining 
responses. 

Concise  mode  is  signified  by  preceding  the  command  name  with  "C-" 
(without  the  quotes). 

1-3.  The  Current  Directory  and  Current  Data  List. 


MOPADS  data  bases  are  made  up  of  multiple  directories, 
each  of  which  may  own  one  or  more  directories  and  data  lists.  Normally, 
the  User  Interface  operates  on  one  directory  which  is  designated 
"current."  Similarly,  one  data  list  of  the  current  directory  can  be 
designated  the  current  data  list.  This  ensures  that  the  action  of  User 
Interface  commands  are  unambiguous.  Facilities  are  provided  for  deter¬ 
mining  the  current  DB  and  DL  and  for  selecting  a  DR  and  DL  to  become 
current .  Note  that  same  commands  automatically  change  tbe  current  DR 
and  DL. 


2-0  BASIC  DATA  BASE  COMMANDS. 

2—1.  CLOSE. 

The  CLOSE  command  (Figure  A-2)  will  close  either  the  working 
or  reference  data  base.  It  can  be  used  to  switch  to  a  new  data  base  file. 

2-2.  CURRENT. 

The  CURRENT  command  (Figure  A-3)  will  display  label,  ID 
or  both  of  the  current  directory  and/or  data  list  on  either  data  base. 

2-3.  DEPOSIT. 

DEPOSIT  (Figure  A-k)  is  a  low  level  editing  command  that 
allows  any  element  of  the  current  data  list  to  be  changed.  DEPOSIT 
interactively  requests  element  numbers  and  new  values. 

2-U.  DIRECTORY. 

DIRECTORY  (Figure  A-5)  shovs  the  contents  (all  owned  direc¬ 
tories  and/or  data  lists)  of  the  current  directory  on  either  data  base. 

It  shows  the  labels,  ID’s,  and  directory  positions  of  the  contents. 

This  information  is  useful  for  the  SELECT  command. 
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Figure  A-2.  CLOSE  Command  Specifications 
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DEPOSIT  Command  Specifications 


Figure  A-5.  DIRECTORY  Command  Specifications 


2-5.  EXAMINE 


EXAMINE  (Figure  A-6)  vill  display  selected  contents  of 
the  current  data  list  to  the  terminal  or  to  the  M0PAD5  line  printer 
output  file.  If  the  latter  is  selected,  the  data  list  label  and 
other  information  vill  also  be  printed. 

2-6.  HELP. 

HELP  (Figure  A-7)  vill  print  the  prompts  and  options  for 
the  prompts  for  the  specified  command. 

2-7.  MENU. 

MENU  has  no  prompts.  It  vill  print  all  commands  available 
in  the  current  subprocess. 

2-8.  OPEN. 

OPEN  (Figure  A-8)  vill  open  a  data  base  file  as  either  the 
vorking  or  reference  DB.  OPEN  vill  not  automatically  close  the  current 
DB.  CLOSE  must  be  used  explicitly  before  OPEN  to  switch  DB  files. 
MAXRECORD  is  the  maximum  number  of  records  all  owed  in  a  data  base  file. 
It  may  not  be  needed  for  your  computer.  Zero  implies  no  limit  on  the 
file  size.  The  (MASTER-DIRECTORY)  is  current  after  the  OPEN  command. 

2-9.  FLHTK. 

PL  INK  (Figure  A-9)  vill  change  the  current  directory  to 
the  owner  of  the  directory  which  was  current  when  PLINK  was  issued. 

2-10.  QUIT. 

QUIT  has  no  prompts.  It  causes  the  current  subprocess  to 

be  exited. 

2-11.  SELECT. 

SELECT  (Figure  A-10)  changes  the  current  directory  or  data 
list  to  one  that  is  owned  by  the  directory  that  is  current  when  SELECT 
is  issued.  The  desired  DR  or  DL  is  selected  by  specifying  one  (and  only 
one)  of  the  following:  1  -  its  directory  position,  2  -  its  label,  or 
3  -  its  ID.  This  information  is  obtained  with  the  DIRECTORY  command. 

2-12.  TERMINATE . 

TERMINATE  has  no  prompts.  It  vill  close  all  open  data  bases 
and  termiacte  execution.  This  is  the  normal  way  to  end  a  User  Interface 
session. 
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Figure  A -6.  EXAMINE  Conanand  Specifications. 
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Figure  A-7-  HELP  Command  Specifications 
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Figure  A-8.  OPEN  Command  Specifications 
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Figure  A-9.  PLIKK  Command  Specifications 


f 


1 

i 

I 


J— 57 


Figure  A-jO.  SELECT  Command  Specifications 


3-0  USER  dSTltjCTIOHS  AHD  EXAMPLES. 

Figure  A— 3  L  iu  an  example  using  all  of  the  Basic  Data  Base 
Commands.  The  annotations  are  explained  below. 
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The  CLOSE  commands  disassociates  the  current 
data  base  file  from  the  MOPADS  software.  After 
close,  MOPADS  will  know  no  working  LB.  If  STATUS 
is  specified  as  DELETE,  the  data  base  file  will  be 
destroyed  p eminently. 

OPEN  associates  the  data  base  file  VOLWLDBF 
to  the  software  as  the  working  DB.  STATUS=OLD 
implies  that  the  DBF  was  previously  created  as  a 
!  MOPADS  data  base  file.  If  STATUS*NEW  is  specified, 
j  MOPADS  will  create  a  new  MOPADS  DB  on  V0U6.DBF, 
i  and  any  information  previously  contained  on  VOLI46.BBF 
will  be  lost. 

The  MENU  command  is  always  available  to  list  the 

commands  currently  available. 

i 

1 

HELP  prints  information  about  a  particular  command. 

The  user  has  asked  for  information  on  the  prompts 
DISPLAY  and  TYPE.  For  DISPLAY,  MOPADS  shovs  that 
it  expects  a  response  of  one  character  string  that 
must  be  one  of  the  enumerated  values  LABEL  (display 
the  label),  ID  (display  the  ID),  or  ALL  (display  both 
label  and  ID).  The  default  is  LABEL.  HELP  is 
terminated  by  entering 

When  OPEN  is  issued,  the  (MASTER-DIRECTORY)  becomes 
current.  The  CURRENT  command  will,  not  display  a 
directory  which  has  no  owner,  which  of  course,  the 
MASTER-DIRECTORY  does  not. 

The  DIRECTORY  command  will  always  work,  however,  even 
on  the  (MASTER-DIRECTORY).  The  contents  of  the  (MASTER- 
DIRECTORY)  are  shown. 

The  SELECT  command  makes  the  REFEREN CE-ADSM  directory 
current  by  specifying  its  directory  position  in  the 
( MASTER-DIRECTORY ) . 

The  DIRECTORY  command  confirms  that  REFEREN CE-ADSM 
is  current  and  shows  the  owned  reference  ADSM's  (in 
this  case  only  one,  E- EXAMPLE). 
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Figure  A-ll.  Example  Using  Basic  Canmands. 
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Figure  A-ll.  (continued) 
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Figure  A-ll.  (continued). 
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Figure  A-ll.  (continued) 
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Figure  A-ll. 
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Select  E-EXAMPLE  to  tie  current. 

Look  at  the  data  list  directory  of  E-EXAMPLE. 

This  operator  state  vector  -will  be  edited. 

The  SELECT  command  makes  the  above  operator  state 
vector  the  current  data  list.  This  is  confirmed 
■with  the  following  CURPENT  command. 

EXAMINE  specifies  that  the  data  list  is  to  be  dis¬ 
played  at  the  terminal.  The  user  wants  row  2. 
HEADER=Y  causes  the  "DATA  LIST  REPORT"  and  the 
next  6  lines  to  be  printed. 

This  display  demonstrates  that  the  basic  data  base 
commands  are  low  level  commands;  they  know  nothing 
about  the  structure  or  contents  of  MOPADS  data  bases. 
The  operator  state  vectors  have  two  rows.  The 
second  row  contains  the  reference  values  for  each 
column.  Prior  to  a  simulation,  the  second  row  is 
conied  to  the  first  row,  which  is  dynamically 
accessed  during  the  simulation.  In  this  way,  the 
reference  or  starting  values  are  not  lost.  MOPADS 
stores  column  labels  only  for  the  first  row,  however, 
since  it  would  double  the  storage  requirement  to 
duplicate  the  labels  for  each  row.  The  ’’CREATE/EDIT 
REFERENCE  SYSTEM  MODULE"  subprocess  knows  all  of 
this,  so  when  a  listing  is  obtained  with  the  CHARGE 
command  in  that  subprocess,  the  labels  appear  with 
the  reference  values. 

The  EXAMINE  command,  however,  simply  operates  on  a 
data  list  without  knowledge  of  the  meaning  of  its 
contents.  Here,  all  of  the  elements  of  row  2  appear 
to  be  (UNLAB El .ED).  Also,  EXAMINE  prints  the  entire 
row.  Only  a  portion  of  the  listing  is  shown  here 
for  brevity . 

Use  the  DEPOSIT  command  to  change  elements.  It  too 
is  a  low  level  command,  so  (row,  column)  addressing 
must  be  used. 

Elements  IT,  18,  and  19  of  row  2  are  changed  (these 
are  operator  trace  parameters). 

This  demonstrates  MOPADS  response  to  input  errors. 

The  DEPOSIT  command  had  not  yet  terminated  when  the 
user  entered  the  next  EXAMINE.  MOPADS  is  expecting 
a  numeric  value  for  a  row  number.  The  free-format 
input  processor  examines  every  input  string  for  * 
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validity  before  process!’.?  it.  Bivzt  "EXAMTSE" 
is  cot  a  valid  number,  lx  u.\trt«  the  error  at  tsage 
and  zettuests  correct  inuut.  *.  thnut  this  feature, 
the  program  would  terminate  atiora&lly  ftm  simple 
typing  errors  and  perhaps  damage  the  datr  base. 

MCPADS  vill  protect  the  user  from  most  such  errors. 

CURRHCT  rliows  that  E-EX/MTLE  la  the  current  directory. 

PLUCK  makes  the  current  directory  eq'tal  to  the  owner 
of  the  directory  that  was  current  when  PLUCK  vas  issued. 

The  CUPJCTT  c  remand  confirms  that  the  REFERENCE- ADSM 
directory  is  now  currant.  Bote  that  when  the  current 
directory  is  changed,  the  current  data  list  becomes 
undefined. 

QL7T  exits  thf-  current  subprocess  and  brings  up  the 
subprocess  option  menu  again. 

The  TERM  command  terminates  execution.  Selecting 
the  xero  option  on  the  subprocesa  selection  menu 
accomplishes  the  same  thing. 
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I  INTRODUCTION 


This  report  suwrizes  the  literature  which  was  reviewed  as 
part  of  the  MGPADG  effort.  In  this  section,  we  will  describe  the 
literature  detabase  .search  logic  used  and  the  way  in  which  the 
literature  was  summarized. 

1.1  SEARCH  LOGIC 

Essentially,  two  search  modes  were  employed.  First,  a  computer 
literature  search  was  conducted  on  the  OTIC  and  Psychological  Abstr¬ 
acts  files  of  the  DIALOG  database.  The  underlying  search  theme  was 
Quantitative  Human  Performance  Models,  although  an  iterative  Bearch 
procedure  yielded  a  number  of  key  words  which  might  yield  literature 
relevant  to  this  topic.  A  total  of  350  abstracts  were  reviewed,  from 
which  115  articles  were  selected  as  potentially  useful  for  the  pro¬ 
posed  effort. 

During  the  review,  the  reference  sections  of  particularly 
interesting  articles  were  examined.  Those  references  which  were  not 
already  in  the  inventory  were  ordered  and  also  reviewed.  The  two 
most  noteworthy  articles  with  respect  to  good  reference  sources  are 
listed  under  reference  notes  at  the  end  of  this  section. 

Each  article  was  given  a  cursory  review  to  determine  its 
potential  utility,  and  If  this  decision  was  positive,  a  more  thorough 
review  was  conducted.  This  thorough  review  was  s\xrnmarized  on  a  form, 
see  Figure  1. 

1.2  LITERATURE  SUMMARY  FORMAT  DESCRIPTION 

Each  model  within  an  article  was  summarized  on  a  form  as  shown 
in  Figure  1.  Because  some  articles  included  a  number  of  human  per¬ 
formance  models,  it  was  frequently  the  case  that  an  article  was 
summarized  on  a  number  of  forms. 
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The  categv ries  ci  the  forms  are  defined  as  follows: 

1.  Reference  -  Information  regarding  author ( s ) ,  title, 
and  ct.,.ar  source  data. 

2.  Appropriateness  -  A  judgement  was  made  b'.r  the  re/iewer 
regarding  the  extent  to  which  this  article  would  be  use¬ 
ful.  These  Judgements  were  based  -jpc.i  two  criteria. 

First,  did  the  article  present  a  significant  contribution 
to  human  performance  modeling?  If  the  anawer  was  yc.--., 
the  article  was  appropriate.  If  not,  did  the  article 
provide  data  which  would  bo  useful  for  modeling  or 
validating  ail  defense  sycteis?  In  other  words,  while 
the  article  may  not  be  generally  useful  for  modeling, 
could  it  provide  scv.e  task  specific  information?  If  so, 
the  article  was  expropriate.  Appropriateness  was  treated 
as  a  continuous  variable,  with  answers  ranging  from  yes 
to  maybe  to  no. 

3.  Dependent  Variables  -  The  specific  dependent  variable(s) 
defined  by  the  model  are  described. 

U.  Independent  Variables  -  Independent  variables  which  were 
included  as  mediators  of  the  dependent  variables  are 
defined.  No  units  were  recorded,  but  a  short  description 
was  included. 

5*  Page  -  The  page(s)  where  the  model  was  best  summarized 
was  recorded.  This  was  intended  to  simplify  future 
references  to  the  model. 

b.  Behaviors  -  The  general  behavior  categories  which  were 
modeled  were  defined.  These  categories  were  selected 
from  the  taxonomy  which  is  presented  ir  Table  1.  Normally, 
a  model  would  fit  under  only  one  behavior  category.  If 
this  was  not  the  case,  all  relevant  behavior  categories 
were  listed. 

?.  Quantitativeness  -  Tne  degree  of  quantitative  model 

development  was  recorded.  The  lowest  degree  of  quanti¬ 
tativeness  was  nominal,  or  zero  quantitativeness.  This 
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implied  vh.it  oruy  c.  verbal  description  of  the  relation¬ 
ship  between  the  independent  and  dependent  variables 
was  provided.  The  next  le/el  was  unsealed  graphs ,  in 
which  the  independent  and  dependent  variables  were 
presented  as  constructs  without  specific  units.  The 
third  level  was  .ahles ,  or  scaled  graphs,  in  which  units 
were  attached  to  independent  and  dependent  variables. 
Finally,  the  highest  level  was  functional  in  which  case 
specific  mathematical  models  were  presented. 

8.  Supporting  Data  -  The  extent  to  which  themodel  was 
supported  by  data  was  determined.  If  not  data  or 
references  were  presented.  "No  Validation"  was  indicated. 
If  the  d"*a  were  questionable,  this  was  also  indicated. 
Admittedly,  this  judgement  was  largely  subjective,  how¬ 
ever,  it  may  help  us  identify  those  models  whicn  we 

wish  to  incorporate  later.  At  some  point,  this  judge¬ 
ment  must  he  made. 

9.  Comments  -  Additional  comments  were  recorded. 


Reference  Notes 

Siegel,  A.,  et  al.  Human  Performance  in  Continuous  Operations.  197?. 

Pew,  R. ,  et  al,  A  Critical  Review  and  Analysis  of  Performance 
Models  Applicable  to  Man-Machine  Systems  Evaluation,  1977 • 


Reference 


Appropriate 


Dependent  Variables 


Independent  Variables 


Pa^e 


Behaviors 


Quant itativeness 


Supporting  Data 

□  Ro  Validation 

□  Validation  with  Questionable  Results 

□  Validated 


Comments 

Figure  1.  Literature  Survey  Form. 
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Table  1 


SKILLS  TAXONOMY 


GENERAL  BEHAVIORS 
VIGILANCE 

PROBABILITY  ESTIMATION 

TIME  ESTIMATION 

HUMAN  RELIABILITY  ASSESSMENT 

MEANINGFUL  MEMORY  ABILITY 

VERBAL  KNOWLEDGE 

WORD  FLUENCY 

NUMERICAL  ABILITY 

CONCEPT  FLUENCY 

DISCOVERY  OF  PRINCIPLES 

FLEXIBILITY 

SYMBOL  MANIPULATION 

DECISION  MAKING 

INTELLEGENCE 

FINE  MANIPULATIVE  ABILITIES 

POSITION  ESTIMATION 

GROSS  MANIPULATIVE  ABILITIES 

CONTROL  PRECISION 

SPEED  OF  ARM  MOVEMENT 

MULTILIMB  COORDINATION 

POSITION  REPRODUCTION 

MOVEMENT  ANALYSIS 

MOVEMENT  PREDICTION 

ACCELERATION  CONTROL 

REACTION  TIME 

TRACKING 

DETECTION 

DISCRIMINATION  ABILITIES 
TIME  SHARING 

CLOSURE  ABILITIES (PERCEPTUAL) 

AUDITORY  ABILITIES 

SPATIAL  ABIL I TI ES-OR I ENTATION 

SPATIAL  AB I L I T I ES-V I SUAL I Z ATI  ON 

ASSOCIATE  MEMORY-ROTE  MEMORY 

ASSOCIATE  MEMORY-MEANINGFUL  MEMORY 

MEMORY  SPAN-SHORT  TERM  MEMORY 

MEMORY  SPAN-INTEGRATION  OF  INFORMATION 

VISUAL  MEMORY 

EXPLOSIVE  STRENGTH-GENERAL 
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Table  1  (continued) 


EXPLOSIVE  STRENGTH-LEG  EMPHASIS 

EXPLOSIVE  STRENGTH-UPPER  BODY  EMPHASIS 

STATIC  STRENGTH-ARM/HAND/SHOULDER  1 

STATIC  STRENGTH-LEG/TRUNK 

DYNAMIC  STRENGT  i-ARMS 

DYNAMIC  STRENGTH-LEGS 

TRUNK  STRENGTH 

EXTENT  FLEXIBILITY 

DYNAMIC  FLEXIBILITY 

GROSS  BODY  EQUILIBRIUM 

BALANCE- VISUAL  CUES  • 

GROUP  COOPERATION 
GROUP  COMMUNICATION 
LEADERSHIP 

GENERAL  COGNITIVE  ABILITIES 


GENERAL  PHYSICAL  ABILITIES 


I 


Siegel,  A.!.,  Pfeiffer,  M.G.,  Kopstein,  F.F.,  Wilson,  L.G.,  and 
Reference  Ozkaptan,  H.  Human  performance  in  continuous  operations:  Volume  I. 

Human  performance  guidelines.  Alexandria,  VA:  US  Army  Research  Inst 
for  the  Behavioral  Sciences,  Research  Product  80-4a,  Decent  er  1979, 
Contract  No.  DAHC-19-C-0054.  ADA086131 


Appropriate  High 


Dependent  Variables  Effectiveness 

estimate  for  armor  tasks 


Independent  Variables  Mission  hours; 

Platoon  leader. 

Squad  leader 

Gunner/Carrier  team  leader 
Maneuver  team  member 


Page 

76 


Behaviors 

General 


Quantitativeness 

Unsealed  Graphs 


Supporting  Data 

fxl  Ho  Validation 

□  Validation  with  Questionable  Results 

□  Validated 

Comments 


1 


!  Reference  Siegel,  et  al  (1979) 

Contract  No.  DAHC-19-C-0054 

I  " 


Appropriate  High 


Dependent  Variables  Effectiveness  estimate  for  armor  tasks 


I 

* 


*. 


c 


Independent  Variables 


Mission  hours 
Squad  and  plato  on 


1  ' 

ef 

> 

> 

> 

V 

r 


I 


*■«•  78 


Behaviors 

General 


Quantitativeness 


Supporting  Data 


•*W 

» 


Unsealed  graphs 

[T]  No  Validation 

|  1  Validation  with  Questionable  Results 
[~~|  Validated 


Co aments 


Reference 


x 


t 


Siegel  et  al  (1979) 

Contract  No.  DAHC-19-C-0054 


•  / 

* 

I - 

I  Appropriate  Yes 

i 

t 

j  Dependent  Variables 

,  Effectiveness  estimate  for  armor  tasks 

t 


! 


i 


Independent  Variables 

Mission  hours 

Best  and  worst  conditions  for  mechanized  infantry 


V 

P»g«  79 


Behaviors 


General 


i 


Quantitativeness 


Unsealed  graphs 


Supporting  Data 


» 


Q  No  Validation 

j  |  Validation  with  Questionable  Results 
[“"I  Validated 
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Comments 


Reference 


Siegel,  et  al  (1979) 
Contract  No.  DAHC-19-C-0054 


Appropriate  High 


impendent  Variables 

Effectiveness  estiante  for  araor  tasks 


Independent  Variables 

Duty  position; 

Squad  vs.  platoon;  day  1,3,5 


Page 

77 

Behaviors 

General 

Quantitativeness 

Table 

Supporting  Data 


[xj]  No  Validation 

n  Validation  with  Questionable  Results 
I"!  Validated 


Consents 


Reference 


Siegel,  et  al  (1979) 
Contract  No.  DAHC-19-C-00S4 


r 


Appropriate 

r  High 

Dependent  Variables 

Projected  effectiveness  rating  for  critical  combat  armor  tasks 

Independent  Variables 

Specific  task 

Duty  position 

Platoon  action 

( 

Pa8«  82-86 

• 

Behaviors  General  • 

Quantitativeness 

Table 

Supporting  Data 

JJP  No  Validation 

|  1  Validation  with  Questionable  Results 

n  Validated 

Consents 


Reference 


Siegel,  et  al  (1979) 
Contract  No.  DAHC-19-C-0054 


1 


r 


K— 17 


Reference 

Siegel,  et  al  (1979) 

Contract  No.  DAHC-19-C-0054 

1 

f 

Appropriate 

High 

Dependent  Variables 

Mean  time  off  target;  mean  •  of  times  off  target 

i 

i 

i 

Independent  Variables 

Hours  of  work  with  15  minutes  rest  every  5  hours, 
for  15  hours 

i 

i 

Page 

93 

Behaviors 

Tracking 

Quantitativenes  s 

Scaled  graphs 

Supporting  Data 

[71  No  Validation 

I  |  Validation  with  Questionable  Results 

□  Validated 

Comments 
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Reference 


Siegel,  et  &1  (1979) 
Contract  No.  DAHC-19-C-0054 


Appropriate 


Dependent  Variables 


High 

t  II  II . — ■ — — « — «i — — — ■— — w— — — — m—m amm 

Percentage  of  signals  detected 


Independent  Variables 

Test  session  10  minute  blocks;  varied  number  of  signals; 
varied  proportion  of  target  signals,  among  all  signals 


Page 

Behaviors 

Quanti tativenes  s 


97 

Detection 

Scaled  Graphs 


Supporting  Data 


Comments 


£7)  No  Validation 

1  |  Validation  with  Questionable  Results 
FI  Validated 

n 

I 
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Comments 


Hick's  Law 


Reference 


Siegel,  et  si  (1979) 
Contract  No.  DAHC-19-C-0054 


Appropriate 

High 


Dependent  Variables 

Pointing  error  (degrees) 


Independent  Variables 

Practice  (4  trials)  or  familiarity  with  area; 
Good  vs.  poor  sense  of  direction 


106,  107 


spatial  orientation,  spatial  visualization, 
position  reproduction;  meaning  full  memory  ability 

Quantitativeness 

Scaled  graphs 

Supporting  Data 

No  Validation 

j  |  Validation  with  Questionable  Results 
|  |  Validated 


Page 


Behaviors 


Comments 


Graph  and  nomograph 


Reference 


Siegel,  et  al  (1979) 
Contract  No.  DAHC-19-C-0054 


Appropriate 


Dependent  Variables  probability  of  detecting  a  moving  target 


Independent  Variables 


Target 

moving 


distance  traveled, 

toward  or  awry  from  viewer  at  9km/hr 


Target  brightness  in  foot  laraberts 


Page 


Behaviors 


111 

I 


Detection 


Quantitativeness 


Scaled  graphs 


Supporting  Data 

No  Validation 

□  Validation  with  Questionable  Results 

□  Validated 

Comments 


Reference 


Siegel,  et  al  (1979) 
Contract  No.  DAHC-19-C-0054 


Appropriate 

Yes 

Dependent  Variables 

-  Distance  of  target  travel  (meters) 


Independent  Variables  Luminance  0f  surround  (foot  lamberts); 

monocular  vs.  binocular  viewing 
movement  is  toward  or  away  fTom  viewer 


Behaviors 


Detection 


Quanti tat ivenes  s 


Scaled  graphs 


Supporting  Data 

{TJ  No  Validation 

□  Validation  with  Questionable  Results 

n  Validated 


Comments 


Siegel,  ec  al  (1979) 

Reference  Contract  No.  DAHC-19-C-0054 


Appropriate  yes 


Dependent  Variables  Time  t0  detect  (sec>) 


i 

\ 


I  > 
j _ ; 


Independent  Variables  Speed  of  tank  (ka/hr). 

Monocular  vs.  binocular  viewing 


Page 


Behaviors 


Quantitativeness 


Supporting  Data 


111 


Detection 


Scaled  graphs 


9 


Comments 


[x~|  No  Validation 

I  |  Validation  with  Questionable  Results 
□  Validated 


m 


Reference 


Siegel,  et  al  (1979) 
Contract  No.  DAHC-19-C-0054 


Dependent  Variables  Handstrength  (0/0) 


Supporting  Data 


□  No  Validation 

□  Validation  with  Questionable  Results 

□  Validated 

<■'  Coa-iients 

This  is  extremity  strength.,  not  gross  body  movement 
ability  or  fine  manipulation. 

This  may  ho  an  approximation  to  fine  manipulation  ability 
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^Tfc~AT^.V.vj-#j>pjwv»v'irc  imncn 

Reference 


ITJ  rj  m«  jvu  r-v  irv  nut  aa  « 


Siegel,  et  al  (1979) 
Contract  No.  DAHC-19-C-00S4 


1 


r 


Appropriate 


Yes 


c- 

I 


Dependent  Variables 


Number  of  arithmetic  sums  done 
(numerical  ability) 


> 

a 


B  ( 


ix. 


£ 


Independent  Variables 


Time  of  day; 

days  of  continuous  duty 

night  duty 


Page 


117 


r 

s 

Eeh''viors 

numerical  ability 

rl 

t : 

u  J 

Quantitativeness 

unsealed  graphs 

r  - 

■- 

Supporting  Data 

f^"l  No  Validation 

r 

1  |  Validation  with  Questionable  Results 

f~]  Validated 


Comments 
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Reference 


Siegel,  et  al  (1979) 
Contract  No.  DAHC-19-C-0C34 


1 


Appropriate 


Yes 


/Dependent  Variables 


Percentage  of  efficiency 


Independent  Variables 

Skin  temperature  of  hand 

Two  oanipulations  and  dynamometer 


Page 

125 

• 

Behaviors 

Fine  manipulative  abi '  ties 

Quantitativeness 

Unsealed  graphs 

Supporting  Data 

El 

No  Veil dat ion 

□ 

Validation  with  Questionable  Results 

□ 

Validated 

Comments 
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Reference  Siegel,  et  al  (1979) 

Contract  No.  DAHC-19-C-0054 


Appropriate 

Yes 

Dependent  Variables 

Change  in  tiae  to  complete  task  (sec). 

Independent  Variables 

Hand-skin  temperature 

exposure  tiae  (min) 

I 


Page 

12S 

Behaviors 

Fine  manipulative  abilities 

Quantitativeness 

Scaled  graphs 

Supporting  Data 

fx]  No  Validation 

I  |  Validation  with  Questionable  Results 

I"!  Validated 

Comments 

Knot  tying  task 

K-28 


✓ 

Reference 

1 

| 

Siegel,  et  al  (1979) 

Contract  No.  DAHC-19-C-0054 

i 

1 

1 

1 

' 

1 

i 

\ 

i  * 

\ 

•  Appropriate 

1 

* 

Yes 

Dependent  Variables 

percent  detections 

|  Independent  Variables 

f 

1 

<  *• 

4 

hours  of  sleep  deprivation 

1  or| 2  nights 

i 

1 

! 

i 

r 

• 

* 

Page 

127  * 

• 

1 

*y 

■ 

Behaviors 

auditory  detection 

i 

.  !  ...  . .  .  _  .  . 

Quantitativoness 

Scaled  graphs 

!« 

Supporting  Data 

g  No  Validation 

1 

1  |  Validation  with  Questionable  Results 

V 

1 

|  |  Validated  } 

s 

> 

1 

% 

% 

% 

Comments 

1 

•ft 

l 

K-29 

1 

Reference 


Siegel,  et  al  (1979) 
Contract  No.  DAHC-19-C-00S4 


Appropriate 

Yf  * 

Dependent  Variables 

percentage  error 

j 

Independent  Variables 

Time  per  movement  (.2  to  1.4  sec) 
eyes  closed  (no  light)  vs.  eyes  open 


, 


Page 

130,  131 

Behaviors 

Gross  positioning  and  movement  abilities;  perceptual  speed 

Qunnti tat ivenes s 

Unsealed  graphs 

Supporting  Data 

• 

H  No  Validation 

|  |  Validation  with  Questionable  Results 

□  Validated 

Co  laments 

Nomograph  p.  131 
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Refei race 


1 


Siegel,  et  al  (1979) 
Contract  No.  0AHC-19-C-0054 


Appropriate  yes 


Dependent  Variables 

Words  heard  perfectly  (0/0) 


Independent  Vnrlnbln.  „  sp„ch 

ratio  (ratio  and  db) 
with  and  without  seeing  speaker 


Page 


134 


Behaviors 


Quantitativeness 


Supporting  Data 


Comnents 


Auditory  identification  abilities 


scaled  graphs 


i~Tl  No  Validation 

□  Validation  with  Questionable  Results 
("I  Validated 

Decrement  due  to  lack  of  vision  under  degraded 
speech  conditions. 

See  also  p.  177 


K-31 


Reference 


Siegel,  et  al  (1979) 
Contract  No.  DAHC-19-C-0054 


r 


Appropriate 

Yes 

s 

Dependent  Variables 

Minimum  target  detection  distance 

! 

Independent  Variables 

Light  level; 
contrast  ratio 

type  of  target  (tank,  jeep,  person) 

i 


Page 

141 

Behaviors 

Detection 

Quantitativeness 

Scaled  graphs 

Supporting  Data 

EH 

No  Validation 

□ 

Validation  with  Questionable  Results 

□ 

Validated 

Consents 

Nomograph  p.  142 

K— 32 


Reference 


Siegel,  et  al  (1979) 
Contract  No.  DAHC-19-C-0054 


Appropriate 

Yes 

Dependent  Variables 

percent  increase  in  errors 


Independent  Variables 

Time  of  day; 
days  without  sleep 


Page 


146 


Behaviors 


Quantitativeness 


Supporting  Data 


Comments 


perceptual  speed,  discrimination 
unsealed  graphs 

□  No  Validation 

□  Validation  with  Questionable  Results 

□  Validated 


K— 33 


Reference 


Siegel,  et  al  (1979) 


Appropriate 


Dependent  Variables 

Recommended  hours  of  recovery. 


Independent  Variables 

Hours  of  sleep  loss,  starting  at  24 


Page 


146 


Behaviors 


General 


Quantitativeness 

Scaled  Graphs 

Supporting  Data 

{3  No  Validation 

□  Validation  with  Questionable  Results 
I  |  Validated 


l 

i 

i 


i 3 

t 


Comments 


See  p.  93,  117  also 


Reference 

Siegel,  et  al  (1579) 

1 

'  I*;)’ 

Appropriate 

Yes 

S3 

V'll 

Z*q 

Dependent  Variables 

hits  (shooting  personal  weapons);  variability 

| 

Independent  Variables 

sleepless  days, 

anchor  performance  before  sleeploss  and  after  recovery; 

0,  1.5,3  hours  sleep/night 
predictable  targets  -  p.  149 
unpredictable  targets  -  p.  150 

- m 

U»2i 

rn 

Page 

149,  150 

1 
_ r-jj 

Behaviors 

discrimination,  perceptual  speed;  gross  positioning 
fine  manipulative  abilities 

5 

Quantitativeness 

scaled  graphs 

_ 

Supporting  Data 

[31  No  Validation 

.4 

k 

£a 

|  |  Validation  with  Questionable  Results 

77. 

f~x]  Validated 

if 

Comments 

(Si 

See  p.  1^6,  93,  117  also 

nr< 
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Reference 

Siegel,  et  al  (1979) 

i 

l 

Appropriate 

Yes 

Dependent  Variables 

i 

| 

percent  of  signals  detected 

Independent  Variables 

minutes  on  watch; 
jauditory,  visual,  both 


j 

i 


Page 


154 


Behaviors 

detection,  auditory  detection 

Quantitativeness 

unsealed  graphs 

Supporting  Data 

I 

□  No  Validation 

□  Validation  with  Questionable  Results 
[2  Validated 

Nomograph  on  p.  155 


Comments 


Reference 


Siegel,  et  al  (1979) 


Dependent  Variables 


0/0  visual  acuity 


Independent  Variables 


degrees  from  fovea 


Behaviors 


detection,  discrimination 


Quantitativeness 


unsealed  graphs 


Supporting  Data 


FI  No  Validation 


f~~|  Validation  with  Questionable  Results 


□  Validated 


Comments 


nomograph  p.  169 


Reference 


Siegel  et  al  (1979) 


Appropriate 


Yes 


Dependent  Variables  mental  perforaance  limit 

tolerable  physical  limit 


6 


f. 


Independent  Variables 


exposure  time 

effective  temperature  or  wet  and  dry  bulb  temp. 


t>  ■ 


v 


►  \ 
k"* 


r 

Page 

171 

K 

K 

£ 

Behaviors 

ft 

nominal 

1 

! .  1 

i 

Quantitativeness 

*  ^ 

i  j  ► 

Supporting  Data 

Cc 
*  * 

0  No  Validation 

□  Validation  with  Questionable  Results 

□  Validated 


Comments 


K-38 


Reference 


Siegel,  et  al  (1979) 


Appropriate  Med. 

Dependent  Variables 

Speech  interference  level  ind  b 


Independent  Variables 

Distance  between  talker  and  listener 


Page 


Behaviors 


177 

auditory  identification  abilities 


Quantitativeness 


Supporting  Data 


scaled  graphs 
j~xl  No  Validation 

|  j  Validation  with  Questionable  Results 
|  |  Validated 


Comments 


See  also  p.  134 
Nomograph  on  p.  178 


Reference 


Siegel,  et  al  (1979) 


Pv 

s 

s 


*  . 


¥ 


Appropriate 

Yes 

Dependent  Variables 

percentage  of  errors 


Independent  Variables 

type  of  noise  -  unpredictable  vs.  predictable 
loud  (108db)  vs.  soft  (56db) 


Page 

184 

Behaviors 

general  reasoning 

Quantitativeness 

unsealed  graphs 

Supporting  Data 

j~xj  No  Validation 

1  |  Validation  with  Questionable  Results 

|  [  Validated 

Co  aments 

See  p.  134,  177 

K-40 


Reference 


Siegel ,  et  al  (1979) 


Dependant  Variables 


probability  of  correct  report 


Independent  Variables 


probability  of  a  false  report 
divided  vs.  undivided  attention 


Page 


187 


Behaviors 


Quantitativeness 


Supporting  Data 


time  sharing 

scaled  graphs 

[£|  No  Validation 

["I  Validation  vith  Questionable  Results 
□  Validated 


f 

& 


* 


s 


t 

i  *, 


Reference 


Siegel,  et  al  (1979) 


Appropriate 

No 

Dependent  Variables 

Independent  Variables 

; 

effects  of  overlearning  and  recall 

Page 

191 

Behaviors 

General 

Quantitativeness 

Supporting  Data 

n  No  Validation 

I  |  Validation  with  Questionable  Results 

n  Validated 

Consents 


K-42 


f 


l 

K 

:$ 

,» 

i_ 

4." 

V* 

i* 


Reference 


Siegel,  et  al  (1973) 


Appropriate 


Yes 


£ 

y 

v 


i 


Dependent  Variables 


mean  accuracy 


t 

.<■ 

I 

A 

.*« 

,*w 

i 


Independent  Variables 


number  of  sleepless  days  of  0,  1.5,  3  hrs  sleep 
per  night 

also,  contains  data  on  ability  prior  to  sleeplessness 
and  following  recovery 


Page 


194 


Behaviors 


t  *  . _ 

discrimination 

i 

r: 

K 

i _ 

Quantitativeness 

1  1 

! 

j  unsealed  graphs 

\ 

5 

» 

y 

% 

6 

'j 

fr 


Supporting  Data 


f71  No  Validation 

□  Validation  with  Questionable  Results 

□  Validated 


Comments 


See  also  p.  117,  127,  146 


K-43 


Reference  Siegel,  et  al  (1979) 


r 

♦ 

! 


Appropriate 

i 

• 

Yes 

|  Dependent  Variables 

1 

1 

t 

* 

Mean  number  of  correct  computations 

! 

|  Independent  Variables 

k 

Time  of  day; 

days  during  a  15-day 

4  hour  on  2  hour  off  work-rest  schedule 

( 

Page 

199 

Behaviors 

numerical  ability 

Quantitativeness 

scaled  graphs 

' 

Supporting  Data 

nq  No  Validation 

n  Validation  with  Questionable  Results 

|  }  Validated 

Comments 

See  also  p.  117,  127,  146,  194 

Nomograph  p.  200 

K-44 


Reference 


x 


Siegel,  et  al  (1979) 


r 


Appropriate 


Yes 


Dependent  Variables 

Decision  accuracy 


Independent  Variables 

Sleepless  days; 

0,  1.5,  3  hours  sleep/night 

Data  on  performance  before  sleeplessness  and 

following  recovery 


Page 

206 

Behaviors 

General  reasoning,  seeing  implications,  practical  judgment 

Quantitativenes  s 

Unsealed  gTaphs 

Supporting  Data 

HI 

No  Validation 

□ 

Validation  with  Questionable  Results 

□ 

Validated 

Comments 

See 

also  p.  117,  127,  146,  194,  199 

K-45 


Reference 


Siegel,  et  al  (1979) 


r 


Appropriate 

Yes 

Dependent  Variables 

mean  number  of  map  reading  errors 

Independent  Variables 

( 

Sleepless  days; 

0,  1.5,  3,  hours  sleep/night 

Performance  data  before  sleeplessness  and 
following  recovery 

Pago 

209 

Behaviors 

Spatial  abilities 

Quantitativeness 

Scaled  graphs 

Support  ing  Data 


j%~]  No  Validation 

□  Validation  with  Questionable  Results 

□  Validated 


Comments 


Reference 

r  ' 

Siegel,  et  al  (1979) 

Appropriate 

Dependent  Variables 

• 

percent  correct  recall 

Independent  Variables 

j 

Duration  of  performance  cf  an  irrelevant  task;  | 

1  to  5  items  to  be  remembered  \ 

t 

1 

; 

i 

t 

) 

t 

i 

Page 

212 

Behaviors 

Meaningful  memory  ability  ! 

! 

i 

Quantitativeness 

i 

Scaled  graphs 

Supporting  Data 

[31  No  Validation 

1  1  Validation  with  Questionable  Results 

jl]  Validated 

Contents 


K-47 


A- 


Nomograph  p.  213 


Reference 


Siegel  et  al  (1979) 


Appropriate 


Dependent  Variables 


Recovery  time 


Independent  Variables 


Adapting  flash  energy; 
target  luminance 


Behaviors 


Vision 


Quantitativeness 


scaled  graphs 


Supporting  Data 


D  No  Validation 

□  Validation  with  Questionable  Results 
m  Validated 


Comments 


K-48 


Reference 

*  pa 

Siegel,  et  al  (1979) 

$n| 

Appropriate 

k 

Yes  $ 

_  .  .  .J 

Dependent  Variables 

•  jub 

Freedom  from  distraction  L* 

Independent  Variables 

Sleepless  days; 

0,  1,5,  3  hours  sleep/night  fe 

Performance  data  before  sleeplessness  and  MjS 

following  recovery 

|W 

is 

i; 

Page 

m  1 

.  ft 

Behaviors 

Conceptual  and  thinking  abilities  W 

a 

Quantitativeness 

;v 

Unsealed  graphs  £,% 

....  *1 

Supporting  Data 

H 

DTI  No  Validation 

to 

1  1  Validation  with  Questionable  Results  ^ 

■\V 

n  Validated  $ 

Comments 

**< 

•"*! 

.*» 

K-49 

Hr 

*  > 


Reference 


Roe,  W.T.  and  Finley,  D.L.  Ergonomic  models  of  human  j 
performance;  source  materials  for  the  analyst. 

Arlington,  VA:  Office  of  Naval  Research,  Technical 
Dept.  August  1975,.  Contract  No.  N00014-74-C-0324  ADAD  20086 


Appropriate 

Medium 

| 

Dependent  Variables 

Energy  expenditure 

- . - . - . -  _ i 

Independent  Variables 

1 

Occupations,  activities,  postures,  types  of  work 

l 

' 

. 

! 

1 

to* 

& 

L 

b 

-  K 

Page 

31-33 

lv 

•  * 

Behaviors 

strength 

>» 

k* 

y 

Quantitativeness 

L 

Tables 

‘  % 
,N 

ton 

Supporting  Data 

|  |  No  Validation 

[.> 

N 

j  |  Validation  with  Questionable  Results 

jw 

0  Validated  1 

1 

» 'j 

b) 

$ 

s* 

Comments 


Reference 

Roe  and  Finley  (1975) 

4  P 

Appropriate 

Moderate 

1$ 

1 

1  """ 

Dependent  Variables 

stress  effects;  heart  rate; 
body  temperature;  sweat  rate 

|| 

Independent  Variables 

heat  stress 

h 

m 

m 

s 

Page 

43 

P 

ki 

[>•’] 

Behaviors 

Physiological  changes 

■ 

Quantitativeness 

Unsealed  graphs 

f.\S 

o 

Supporting  Data 

|  |  Ho  Validation 

* 

*V3 

I  |  Validation  with  Questionable  Results 

[J\;  £ 

K-f 

H3  Validated 

K:| 

. —  -  - .  .  i^V 

Comments 

jsl 

*». 4.  ***!*«  k'"-W  -*>i*  U" 

Intervening  variable  used  as  a  predictor. 

K-51 

, . **>:■<  r>v  j>  ;•> 

rr* 

r.;5 

.*.v 

v.  * 

V-1  ■ 

V-'* 

ft 

Dependent  Variables 


Sensing,  identifying,  interpreting,  controlling 


Independent  Variables 


sensing, 

identifying; 

interpreting; 

controlling 


Behaviors 


Quantitativenes  s 


Supporting  Data 


Comments 


sensing,  identifying,  interpreting,  controlling 

nominal 

1  |  No  Validation 

□  Validation  with  Questionable  Results 
I  |  Validated 


structural  models 


Reference 


4 

Pfeiffer,  MG  and  Siegel,  A. I.  Model  development 

and  the  assessment  of  competing  models.  Santa  j 

Monica,  CA;  Human  Factors  Society,  proceedings  of 

the  18th  Annual  Meeting,  1974,  425-428 


Appropriate 

Yes 

Dependent  Variables 

Aggregate  utility  IL  i 

Independent  Variables 

Importance  weight  of  the  j**1  dimension 

Page 

427 

Behaviors 


Quantitativeness 


Supporting  Data 


System  equalisation  abilities 

Functions 

|  |  No  Validation 

Q  Validation  with  Questionable  Results 
n  Validated 


Co aments 


A 

s, 

r 


I 


Reference 


Appropriate 


Dependent  Variables 


Pfeiffer,  M.G.,  Siegel,  A. I.,  Taylor,  S.E.,  and 
Shuler,  L.,  Jr.  Background  data  for  the  human 
performance  in  continuous  operations  guidelines, 

Alexandria,  VA:  US  frny  Research  Institute  for  the  Behavioral 
and  Social  Sciences l  Technical  Report  386,  July  1979, 

Contract  No.  DAHC19-77-C-00S4 


Minimum  perceptible;  visual  angle 


Independent  Variables 


Background  luminancle  (log  foot-lamberts) 


Behaviors 

i 

Quantitativeness 


Supporting  Data 


Comments 


Discrimination 

Scaled  graphs 

□  NO  Validation 

|  |  Validation  with  Questionable  Results 

I 

□  Validated 


K— 55 


Reference 


Pfeiffer  and  Seigel  (1979) 


| 


Dependent  Variables 


Time  to  recover  visual  ability  from  a  blinding  flash  (seconds) 


Independent  Variables 


Log  adapting  flash  energy 


Behaviors 


Quantitativeness 


Supporting  Data 


Discrimination 


Scaled  graphs 


fiTl  No  Validation 


1  1  Validation  with  Questionable  Results 
n  Validated 


Consents 


K-56 


Reference 


Pfeiffer  and  Seigel  (1979) 


Dependent  Variables 


probability  of  detection 


Independent  Variables 


visual  angle 


Page 


Behaviors 


Quantitativeness 


Supporting  Data 


11 

Discrimination 

Scaled  graphs 

{^]  No  Validation 

□  Validation  with  Questionable  Results 
n  Validated 


Goaaents 


Data  from  Blackwell  (1946).  Actual  presentation 
conditions  uncertain 


w 

11  Reference 

Pfeiffer,  et  al  (1979) 

5 

/ 

| 

|  Appropriate 

1 

High 

j  Dependent  Variables 

Time  to  recover  an  intellective-motor  ability 
following  a  blinding  flash 

Independent  Variables 

Visual  recovery  time; 

Work  area  luminance  in  foot  lumberts; 

Minimum  luminance  to  perceive  the  work  under 

optimum  conditions; 

energy  of  flash  in  ft.l  seconds 

Page 

13 

Behaviors 

Discrimination 

Quanti tat ivenes s 

Functions 

S,  ^porting  Data 

£x]  No  Validation 

|  |  Validation  with  Questionable  Results 

Q  Validated 

Comments 


Reference 


Pfeiffer,  et  al  (1979) 


Independent  Variables 


Distance  in  feet  between  talker  and  listener 


Page  14 

Behaviors 

Scaled  graphs 

Quantitativeness 

Supporting  Data 

pH  No  Validation 

|  |  Validation  with  Questionable  Results 
IP]  Validated 


Comments 


Reference 


Pfeiffer,  et  al  (1979) 


3 


Appropriate 

Med. 

Dependent  Variables 

Rest  required  following  energy 

expenditure 

above  some  standard 

Independent  Variables 

Total  working  time  in  minutes; 
energy  standard 

energy  cost 

in  Cal/min; 

Page 

15,  18  (figure) 

Behaviors 

Stamina 

Quantitati  ,'eness 

Functions 

Supporting  Data 


£TJ  No  Validation 

□  Validation  with  Questionable  Results 
D  Validated 

Comments 

The  figure  on  p.  18  is  for  several  energy  standards, 
and  is  expressed  in  Cal/min  for  energy  and  minutes 
rest  per  hour  worked. 


K-60 


Reference 


Pfeiffer,  et  al  (1979) 


5 


Appropriate 

Yes 

Dependent  Variables 

Mean  choice  Rt 

Independent  Variables 

Number  of  possible  stimuli 

Page 

17 

Behaviors 

Reaction  time 

'Quantitativeness 

Functions 

Supporting  Data 

|  |  No  Validation 

fin  Validation  with  Questionable  Result 

|  |  Validated 

Comments 


Hick's  Law  may  be  too  theoretical  and  over  simplified 
for  MOPADS.  However,  it  may  be  as  good  an  approximation 
as  any  other  formula.  K  is  the  problem 


3 


Reference 


Pfeiffer,  et  al  (1979) 


Appropriate 


Med. 

Dependent 

:  Variables 

Rest  required  following  energy  expenditure  above 
some  standard 

/ 

Independent  Variables 

I  Total  working  time  in  minutes;  energy  cost  in 

Cal/min; 
energy  standard 


/ 


Page 

15,  18  (figure) 

Behaviors 

Stamina 

Quantitativeness 

FuWvions 

Supporting  Data 

[~x]  No  Validation 

|  |  Validation  with  Questionable  Results 

! 

|  [  Validated 

Comments 

The  figure  on  p.  13  is  for  several  energy  standards,  and 
is  expressed  in  Cal/min  for  energy  and  minutes  rest  per 
hour  worked. 


K-62 


O- 


Reference  Pfeiffer  et  al  (1979) 


I 


Appropriate 

# 

Med. 

Dependent  Variables 

Percent  of  omissions 

Independent  Variables 

Speed  X  load 

(signals/min)  X  (number  of  dials  monitored) 

{ 

Page 

j 

17,  19  ! 

Behaviors 

1 

Time  sharing  !., 

Quantitativeness 

Scaled  graphs 

Supporting  Data 

|  |  No  Validation 

|  |  Validation  with  Questionable  Results 

[""I  Validated 

Comments 

Useful  for  a  guess  at  the  slope  of  the  linear  function 

K-63 


Reference 


Pfeiffer,  et  al  (1979) 


Appropriate 


Dependent  Variables 


percent  efficiency 


Independent  Variables 


Skin  temperature  of  hand  three  tasks 


Behaviors 


Quantitativeness 


Supporting  Data 


Fine  manipulative  abilities 


Unsealed  graphs 


Q  No  Validation 

□  Validation  with  Questionable  Results 
HD  Validated 


Comments 


See  Siegel  (1)  for  same  graph 


Reference 


Pfeiffer  et  al  (1979) 


Appropriate 


Yes 


Dependent  Variables 


Change  in  time  to  complete  knot- tying  task  (seconds) 


Indeoendent  Variables 


Exposure  time  (to  cold) 

TVo  hand-skin  temperatures  (55®  and  60°F) 


Page 


21 


Behaviors 


Fine  manipulative  ability 


Quantitativeness 


Scaled  graphs 


Supporting  Data 


□  No  Validation 

□  Validation  with  Questionable  Results 
1*1  Validated 


K-65 


*  v 

.3 


J*  •,*  •  J-  rj»/ 


Comments 


Reference 


Pfeiffer,  et  al  (1979) 


Dependent  Variables 


Productivity  index 


Independent  Variables 


Wet  bulb  temperature 


Comments 


Reference 


Pfeiffer,  et  al  (1979) 


Appropriate 


Yes 

Dependent  Variables 

Error 

Independent  Variables 

Work/rest  schedule  (5/5  to  60/60  minutes/minutes) 
Vibratien/normal  environment 

Page 

23 

'  - 

Behaviors 

Fine  manipulative  ability 

Quantitativeness 

Unsealed  graj-.j 

Supporting  Data 


|  |  No  Validation 

1  1  Validation  #ith  Questionable  Results 
□  Validated 


Comments 


Reference 


Pfeiffer,  et  al  (1979) 


Appropriate 

Yes 

Dependent  Variables 

Transmissibility  of  whole  body  vibration 

Independent  Variables 

Frequency  (Hz) 

Types  of  seats 

Page 

25 

Behaviors 

General 

Quanti tat i venes  s 

Unsealed  graphs 

Supporting  Etta 

□ 

No  Validation 

□ 

Validation  with  Questionable  Results 

□ 

Validated 

Consents 

This 

graph  is  for  conversion  use 

yjrrrwu*  *  Jr*  fh  ^  k*m  w*  rnmn  3sr*m.«pui 


Reference  Pfeiffer,  et  al  (1979) 


3 


/ 


Appropriate 


Dependent  Variables 

Qualitative  assessment 


Independent  Variables 

Frequency  (Hz)  t 

Acceleration  (g)  due  to  whole  body  vibration 


Page 

25 

» 

Beha 

viors 

1 

l 

See  comment 

i 

Quan 

ititativeness 

i 

! 

unsealed  graphs 

Supporting  Data 


Q  Mo  Validation 

I"!  Validation  with  Questionable  Results 
□  Validated 

Cosnents 


This  graph  is  for  assessment  of  subjective  feeling 


Reference 


Pfeiffer,  et  al  (1979) 


Appropriate 

Yes 

Dependent  Variables 

Tracking  error 

Independent  Variables 

Days  of  sleep  deprivation; 

Three  measures  per  day; 

Administration  of  amphetamine 

Page 

27 

Behaviors 

Psychomotor  abilities 

Quantitatiycmess 

Scaled  graphs 

Supporting  Data 

□ 

No  Validation 

□ 

Validation  with  Questionable  Results 

□ 

Validated 

Consents 


Reference 


Pfeiffer,  et  al  (1979) 


r 

Appropriate 

Yes 

Dependent  Variables 

Recommended  hours  recovery 

Independent  Variables 

Cumulative  hours  of  sleep  loss 


Plage 


27 


Behaviors 


Quantitativeness 


Supporting  Data 


General 

Scaled  graphs 

FI  No  Validation 

I"!  Validation  with  Questionable  Results 
n  Validated 


K-71 


Coanents 


Reference 


Pfeiffer,  et  al  (1979) 


r 


Appropriate 

Yes 

Dependent  Variables 

Body  temperature 


Independent  Variables 

Days  of  night  duty; 
Time  of  day 


Page 


Behaviors 


28 

General 


Quantitativeness 


Scaled  Graphs 


Supporting  Data 


Consents 


]  ]  No  Validation 

|  1  Validation  with  Questionable  Results 
□  Validated 

For  conversion  purposes 


K-7? 


Reference 


Appropriate 


Dependent  Variables 


Independent  Variables 


Page 


Behaviors 


Quantitativeness 


Supporting  Data 


Comments 


Pfeiffer,  et  al  (1979) 


5 


Yes 

Number  of  sums  done 

Days  of  Night  duty 
Time  of  day 


28 

Numerical  ability 

Scaled  graphs 

Q  No  Validation 

{  I  Validation  with  Questionable  Results 
□  Validated 


K-73 


Reference 


Pfeiffer,  et  al  (1979) 


3 


Appropriate 

Yes 

Dependent  Variables 

0/0  of  failures  relative  to  24  hour  mean 


i 

i 


J  Independent  Variables 

i 

|  Time  of  day  (9  A.M.  to  9  P.M. ) 

ip  Delay  in  answering  telephone  calls 

l  Frequency  of  errors  in  reading  gas  meters 

f  Frequency  of  falling  asleep  while  driving 

’  Frequency  of  errors  in  answering  warning  signals. 


* 

Page 

28 

i 

Behaviors 

Practical  judgment,  logical  evaluation,  discrinunability 

r 

Time  sharing;  visual  memory 

j 

Quantitativeness 

j 

* _ 

Scaled  graphs 

Supporting  Data 

• 

□ 

No  Validation 

□ 

Validation  with  Questionable  Results 

□ 

Validated 

Comments 


Reference 


Pfeiffer,  et  al  (1979) 


5 


Appropriate 

Yes 

Dependent  Variables 

Limits  for  mental  performance  and  physical  to?~-.ance 

Independent  Variables 

Effective  temperature; 

Exposure  time 

Page 

30 

Behaviors 

Conceptual  and  thinking;  psycho-motor 

Quantitativeness 

, 

Scaled  graphs 

Supporting  Data 

□ 

No  Validation 

□ 

Validation  with  Questionable  Results 

□ 

Validated 

Comments 

K-75 


Reference 

Pfeiffer,  et  al  (1979) 

i  5 

Appropriate 

Yes 

Dependent  Variables 

Comfort  zones 

0/0  relative  humidity 

Effective  Temperature 

.  .  i 

Independent  Variables 

1  I 

i 

*  Dry-bulb,  wet  fyulb  temperature 

Page 

30 

» 

Behaviors 

Mediating  variables 

i 

Quantitativeness 

1  . 

Scaled  graphs 

Supporting  Data 


□  No  Validation 

□  Validation  with  Questionable  Results 

□  Validated 

Comments 

I 

K-76 


X 


/ 

/  l 

Reference 

5 

Pfeiffer,  et  al  (1979) 

• 

Appropriate 

Yes 

Dependent  Variables 

• 

• 

Mean  percent  correct  responses 

Independent  Variables 

Time  duration  (1-6  sec)  following  a  1  sec  11  odb  S  PL  noise 

Noisy  environment  vs.  quiet  environment 

Page 

31 

Behaviors 

perceptual  speed,  practical  judgment,  immediate  memory 

Quantitativeness 

scaled  graphs 

Supporting  Data 

El 

No  Validation 

□ 

Validation  with  Questionable  Results 

□ 

Validated 

Comments 


K-77 


Reference 

Pfeiffer,  et  al  (1979) 

Appropriate 

Yes 

Dependent  Variables 

Average  percent  of  errors  while  proofreading 

Independent  Variables 

Unpredictable  vs.  predictable  vs.  no  noise; 

108  db  vs.  56  db 

Page 


Behaviors 


31 


Word  fluency,  practical  judgment,  visual  memory 


Quantitativeness 

Scaled  graphs 

Supporting  Data 

|  1  No  Validation 

□  Validation  with  Questionable  Results 

□  Validated 


Comments 


Reference 

Pfeiffer,  et  al  (1979) 

5  1 

1 

Appropriate 

Yes 

1 

Dependent  Variables 

Mean  percentage  of  letters  recalled  correctly 

1 

Independent  Variables 

Delay  of  instructions 

(.5  sec  before  to  5  sec.  after  presentation) 
light  vs.  dark 

Si 

1 

1 

ft 

_  _  _  * 

Page 

J 

1 

33 

\ 

k 

::  ehaviors 

immediate  memory 

f 

I 

I 

Quantitat '  s 

scaled  graphs 

t 

i 

i 

Supporting  Data 

|xl  No  Validation 

□  Validation  with  Questionable  Results 

| 

|  |  Validated 

T 

t 

_ . .  1 

Comments 


K-79 


Reference 

Pfeiffer,  et  al  (1979)  @ 

Appropriate 

No  ^ 

Dependent  Variables 

Retention  after  teaming  ^ 

Independent  Variables 

$5 

Days  since  learning;  ig 

100%,  50%,  0%  overlearning  N 

Page 


Behaviors 


Quantitativeness 


36 


Rate  memory 


Scaled  graphs 


Supporting  Data 

HI  No  Validation 

□  Validation  with  Questionable  Results 
1  |  Validated 

Comments 


*> , 

r 

r 

r 


7 


K-80 


s 


.  l.l.  . 

Dependent  Variaoles 

I 

Pointing  error  (du^rees) 


Independent  Variables  1 

Practice  (trials  1-4); 

good  vs.  poor  sense  of  direction  persons 


# 

Page 

36 

i 

1  Behaviors 

i  1 

Spatial  abilities 

Quantitativeness 

Scaled  graphs 

Supporting  Data 

No  Validation 

1 

1 

■  -  | 

1 !  !  Validation  with  Questionable  Results 

|  |  Validated 

Conments 

1 

Large  variability  a;nong  persons 

K-81 


Reference 


Pfeiffer  -  et  al  (1979) 


Appropriate 


Yes 


Dependent  Variables 

Obtained  B  (beta) 


Independent  Variables 

Optimal  B  (beta); 
probabilities  variable; 
Values  variable 


Page 

39 

Behaviors 

General  reasoning;  seeing  implications,  practical 
judgment;  memory  span,  integration 

Quantitativeness 

Scaled  graphs 

Supporting  Data 

fxl  No  Validation 

{  1  Validation  with  Questionable  Results 

|  |  Validated 

Comments 

This  illustrates  the  suboptimal  decision  making 

strategy  of  humans.  Underestimation  of  high 
beta  and  overestimation  of  low  beta. 


Reference 


Pfeiffer,  et  al  (19?9) 


Dependent  Variables 


Probability  of  a  correct  report 


Quantitativeness 


Scaled  graphs 


Comments 


Refererce 


Pfeiffer,  et  al  (1979) 


Appropriate 

Yes 

Dependent  Variables 

Words  correct  (%) 

Independent  Variables 

Speech- to-noise  ratio  (dB) 

Auditory  plus  visual  cues  vs.  auditory 
cues  only 

Page 

41 

Behaviors 

Auditory  perceptual  speed 

Quantitativeness 

Scaled  graphs 

Supporting  Data 

|  |  No  Validation 

I  |  Validation  with  Questionable  Results 

|  |  Validated 

Comments 


Reference 


Pfeiffer,  et  al  (1979) 


Appropriate 

Yes 


Dependent  Variables 

Speed  of  communication 
Richness  of  conmunication 


Independent  Variables 

face  to  face,  voice,  typed  communication  modes 


Page 

40  and  41 

Behaviors 

Auditory  perceptual  speed,  communication  speed 

Quanti.  tativtness 

Scaled  graphs 

Supporting  Data 


]  |  No  Validation 

□  Validation  with  Questionable  Results 

□  Validated 


Comments 


Chaponis  experiments 


Reference 


Pfeiffer,  et  al  (1979) 


5 


l  «ru. 

,V 

,v 

3 


V* 

V* 


v' 

V* 


Appropriate 


Dependent  Variables 


Independent  Variables 


Yes 


Mean  shock  intensity  administered  in  an 
anonymous  envi ronraent 


aggressive,  nonaggressive 
no  model 


Page 

43 

Behaviors 

aggression 

Quantitativenes  s 

unsealed  graphs 

Supporting  Data 

fid  No  Validation 

[J  Validation  with  Questionable  Results 

1  1  Validated 

Comments 

Aggressive  models  increase  aggression 

K-86 


Reference 


Pfeiffer,  et  al  (1979) 


Appropriate 

Yp<; 

Dependent  Variables 

Aggression 

Independent  Variables 

Depersonalization 
Dispersion  of  responsibility 


Page 


Behaviors 


Quantitativeness 


Supporting  Data 


Comments 


42 

Aggression 

Nominal 

□  No  Validation 

□  Validation  with  Questionable  Results 

□  Validated 

Both  IVs  increase  aggression 


K-87 


Reference 


5 


Appropriate 


Dependent  Variables 


Independent  Variables 


Behaviors 


Quantitativenes3 


Supporting  Data 


Mean  shock  intensity  administered 


Aggression  aroused  vs.  nonaroused 
Other  aggressive  stimuli 


Aggression 


Unsealed  graphs 


sn  No  Validation 


|  |  Validation  with  Questionable  Results 


Comments 


|  |  Validated 


Aggressive  stimuli  and  prompting  increase 
aggression 


Reference 


Pfeiffer  (et  al)  1979 


5 


V 


j 

i  r 


Appropriate 

Yes 

Dependent  Variables 

Mean  shock  intensity  administered 

Independent  Variables 

1 

Total  trials 

Reinforcement  vs.  nonreinforcement 

Page 

44 

Behaviors 

Aggression 

Quantitativeness 

Unsealed  graphs 

Supporting  Data 

|  |  No  Validation 

j  1  Validation  with  Questionable  Results 

1  1  Validated 

Comments 

Reinforcement  for  aggression  increases  aggressive 
behavior. 

r-89 


s  •» 


•* 


Reference  Seigel,  A. I.  Human  performance  reliability  -  its  measurement  and  impact 

on  system  reliability.  Paper  presented  at  the  Design  Engineering  Conference 
and  Show.  Chicago,  II:  ASME,  1978,  Report  No.  78-DE-17. 


Appropriate  Yes 


j  Dependent  Variables 

Human  reliability 

|  Independent  Variables 

Human  reliability 

• 

• 

j 

-  No.  failures  * 

Total  attempts 

:  *«•  2 

j  Behaviors 

"General" 

j 

Quantitativeness 

*  Functions 

i 

Supporting  Data 


□  No  Validation 

m  Validation  with  Questionable  Results 
|  [  Validated 

Comments 


K-90 


o 


Reference  Seigel,  A. I.  (1978) 


<" 


Appropriate 

Yes 

Dependent  Variables 

Hunan  availability 


Independent  Variables 


Hunan  availability  *  1 


Time  lost  or  unmanned  hours 
Total  mission  manhours 


Page 

2 

Behaviors 

"General" 

Quantitativeness 

Funcations 

Supporting  U»ta 


n  No  Validation 

m  Validation  with  Questionable  Results 
□  Validated 


Comments 


/ 


Reference 


Seigel,  A.I.  (1978) 


Appropriate 


Dependent  Variables 

Human  MTTR 


Independent  Variables 

Human  MTTR  » 


Total  time  of  second  tr> 
Number  of  second  tries 


Behaviors 


"General" 


Quantitativeness 


Funcations 


Supporting  Data 


Comments 


□  No  Validation 

m  Validation  with  Questionable  Results 

□  Validated 


Bn»l 


Comments 


K-93 


Reference 

Seigel,  A.I.  (1978) 


Appropriate 

Yes 

Dependent  Variables 

Equipment  Availability 


Independent  Variables 

Equipment  availability  «  jHigPiSgS*  UP  time _ 

Equipment  up  time  +  down  time 


Page 


Behaviors 

"General" 


Quantitativeness 

Functions 

Supporting  Data 

□  No  \ Alidation 

El  Validation  with  Questionable  Results 

□  val  x dated 


Comments 


Reference 


Seigel,  A. I.  (1978) 


Appropriate 

2 

Dependent  Variables 

Equipment  MTBF 


Independent  Variables 


Equipment  MTBF 


£  times  between  failures 
Number  of  failures 


Page 

2 

Behaviors 

"General" 

Quantitativeness 

Functions 

Supporting  Data 

|  |  No  Validation 

HD  Validation  with  Questionable  Resul 
□  Validated 

Comments 


Appropriate 


n 

s 


Yes 

Dependent  Variables 

Equipment  MTTR 


Independent  Variables 


_ _  1JWI>  _  Total  Z  MTTR  values  over  all  iterations 

Equipment  wTTR  *  ..  -  >  -  —  m  mm  m  .  _t . • . 1  ■ . ■ . .  1  ■  n . r™ . ■ 

n  r  Number  of  iterations 


a 


Page 


2 


1 

r/ 

K 

Behaviors 

"General" 

Quantitativeness 

£. 

• 

Functions 

»  »' 

Supporting  Data 

□ 

No  Validation 

• 

1 

1 

m 

Validation  with  Questionable  Results 

V 

p  . 

/. 

f”. 

□ 

Validated 

• 

Comments 

f 


K-96 


Seigel,  A. I.  Cl 978) 


Reference 


Appropriate 

Yes 

Dependent  Variables 

System  reliability 


Independent  Variables 


System  reliability 


Number  of  equipment  failures  »  Number  of  second  try  successes 
Number  of  iterations 


* 

I 


Page 

2 

Behaviors 

"General" 

Quantitativeness 

Functions 

Supporting  Data 


I 


W, 


» 


1  |  No  Validation 

□  Validation  with  Questionable  Results 
n  Validated 


Comments 


Reference 


Seigel,  A.I.  Q973) 


Appropriate 


Dependent  Variables 


System  availability 


Independent  Variables 

System  availability  *  1  - 


quipment  down  time  X  Unmanned  hours. 


fission  time 


Quantitativeness 


Functions 


Supporting  Data 


Comments 


|  |  No  Validation 

|T]  Validation  with  Questionable  Results 
j  [  Validated 


K-98 


Reference 

oeigel,  A.I.  (1978) 

r 

6 

Approprirtt 

Yes 

Dependent  Variables 

• 

System  MTTR 

Independent  Variables 

_  KfiTR  »  £  time  ^or  rfePa^rs  *  2  fiae  f°r  second  try  successes 
y  i  r  Number  of  repairs  ♦  Number  of  second  try  successes 


Page 

.  2 


Behaviors 

"General” 


Quantitativeness 

Functions 

Supporting  Data 

Q  No  Validation 

|7|  Validation  with  Questionable  Results 

I 

n  Validated 


Comments 


Reference 


Siegel,  A. I.  and  Federman,  P.J.  Communications  content  training  as 
ingredient  in  effective  team  performance,  Ergononic,  1973,  16C4), 
403-416. 


Appropriate 


Medium 


Dependent  Variables 


Independent  Variables 


Contains  a  taxonomy  of  categories  for  military  radio  communications 
in  an  anti-submarine  warfare  task 


Page 

413 


Behaviors  „Ceneral„ 


Quantitativeness 

Nominal 

Supporting  Data 

n  No  Validation 

El  Validation  with  Questionable  Results 
PI  Validated 

Comments 


ff  M*  'S*  J-V."  -I1  A  *  sl'.T  j-.l  V,k,X',Ji.*Jk.'V,  <■ . na  >.i  s^KucrpacricvCTgjr, 


■.PtUTtr^OB 


Reference 


( 


Siegel,  A. I.,  Leahy,  SLR.  and  Wolf,  J.J.  Human  performance 
tradeoff  carves  for  use  in  the  design  of  Navy  systems:  Final 
Report.  Washington,  DC:  Naval  Sea  Systems  Command,  April  1973, 
Contract  No.  N00G24-76-C-6126  ADA0S3332. 


Appropriate 

Yes 


Dependent  Variables 


Overall  Performance 


Independent  Variables 


Number  of  men  at  each  rank  and  specialty 

Body  weight 

S.D.  of  body  weight 

Summary  and  secondary  specialty  profeciency 
Average  work  pace 

Average  stress  tolerance  threshold 

Average  caloric  intake 

Average  aspiration  interval 

Average  physical  capability 

Average  hours  since  last  sleep 

Average  duration  in  incapacity  (sickness) 
Minimum  fatigue  necessary  for  sleep 

Average  short  term  power  output 

Average  capability  after  a  full  work  day; 
equipment:  failure  rate,  avg.  repair  time, 
S.D.  of  repair  time,  no  men  required  to 
repair,  mental  load,  consumable  use 

Event  data 

p.„.  4 

Behaviors 

Generic  performance 

| 

|, 

Quantitativeness  | 

Nominal 

1 

.  i 
| 

Supporting  Data 

1 

HI  No  Validation 


□  Validation  with  Questionable  Results 

□  Validated 


Comments 

Overall  model  for  this  simulation 


K-101 


Reference 

Siegel,  A. I.,  st  al  0-978) 


Appropriate 

Yes 


Dependent  Variables 


Independent  Variables 

System  reliability  metrics  also  spelled  out  in  other  Siegel  papers 


Page 


Behaviors 

"General” 


Quantitativeness 

Functions 

Supporting  Data 


fTl  No  Validation 

□  Validation  with  Questionable  Results 

□  Validated 


!WBeWBe3BBKmgWf3«HgBBBCmgraPCge^^ 


’.'ymffJ1  rrzy 


Reference 


”5S 

8  8 

!ki 


Siegel,  A. I.,  et  al  (1973) 


Appropriate 

Ifes 


Dependent  Variables 

Mean  hours  worked 


Independent  Variables 

Primary  competence  (high  -  avg. 

Secondary  competence 

Men  per  shift 

Shift  length 

Pace 


low) 


Page 

17-19 

!e 

;* 

j 

3 

Behaviors 

if 

"General" 

3 

. .  (5 

Quantitativeness 

u 

s\ 

Scaled  Graphs , 

Functions  £< 

■N 

Supporting  Data 

•  *  . 

\\ 

no 

No  Validation 

L* 

□ 

Validation  with  Questionable  Results  ^ 

□ 

Validated  Cj 

S 

— * - " - - - - *  ■"■■■■■*  — ■  . . . . . .  . . . . »■- - - - -  - S* 

Comments 


J> 


K-103 


imgrK  m n."wsL- 


Reference 


Siegel,  A. I.,  et  al  (1978) 


Dependent  Variables 


Percentage  of  tasks  performed  successfully  on  the  first  attempt 


Independent  Variables 
Crew  size 
Shift  length 
Primary  competence 
Secondary  competence 
Mental  load 
Pace 

Level  of  aspiration 
Leader's  expectation 


Behaviors 


20-22 


"General" 


Quanti tat i venes  s 

Scaled  Graphs,  Functions 


Supporting  Data 


El  No  Validation 

□  Validation  with  Questionable  Results 

□  Validated 


Comments 


K-104 


rw*  /▼«"« rn?xsnan<«unwr» IWIW irrzmr*  *  » rr ■.  •urn nm mmm» 


Reference 


Dependent  Variables 

Unmanned  station  hours  -  hours  of  work  not  performed  due  to  personnel 
unavilability 


Independent  Variables 
Pace 

Primary  competence 
Level  of  Aspiration 
Leader's  expectation 
Shift  length 
Men  per  shift 


Quanti tat ivenes  s 

Scaled  Graphs,.  Functions 


Supporting  Data 


[FI  No  Validation 

H  Validation  with  Questionable  Results 
1  j  Validated 


Comments 


K-105 


v'rviir.v.V.VATV.Vri*,'’  TUPVMVH-Sir-  *■ 


re-ip. ;  er.  / w*/ .. **-<r ■*/*  *i 


Reference 


Siegel,  A. I.,  et  al  (1978) 


Appropriate 


Yes 


Dep 


ndent  Variables 

Percentage  of  tasks  ignored  due  to  time,  personnel,  or  stress  constraints 


Independent  Variables 
Crew  size 


Pace 

Primary  competence 
Secondary  competence 
Shift  length 
Leader's  expectation 
Level  of  Aspiration 
Mental  load 


Page 

26-28 

Behaviors 

"General" 

Quantitativeness 

Scaled  Graphs, 

Functions 

Supporting  Data 

HI 

No  Validation 

k-.-j 

f  ‘-V- 

□ 

Validation  with  Questionable  Results 

f&i 

□ 

Validated 

- .  1 . - .  . - . - . - 

Comments 

K-106 


Reference 

Siegel,  A. I.,  et  al  (1973) 


Appropriate 

Yes 

Dependent  Variables 

System  reliability  and  system  availability 


Independent  Variables 

Leader  Vs  expectation 
Level  of  aspiration 
Mental  lead 
Men  per  shift 
Shift  length 


Page 

29-32 


Behaviors 

"General" 

Quantitativeness 

Scaled  Graphs, 

Functions 

Supporting  Data 

HI 

No  Validation 

□ 

Validation  with  Questionable  Results 

□ 

Validated 

Comments 


Appropriate 


Yes 


Dependent  Variables 


System  WTTR 

i 


Independent  Variabx  s 
Pace 

Shift  length 
Mental  load 
Aspiration 
Leader's  expectation 


% 


Page 

33-34 


Behaviors 

"General" 


Quantitativeness 

Scaled  Graphs,  Functions 

]  I 
I 

Supporting  Data 

[£]  No  Validation 

□  Validation  with  Questionable  Results 

□  Validated 

Comments 


K-108 


Reference 


Siegel,  A. I.,  et  al  (1978J 


Appropriate 

Yes 

Dependent  Variables 

Human  reliability 


Independent  Variables 

Primary  competence 
Pace 

Shift  length 
Level  of  aspiration 
Mental  load 
Leader's  expectation 


Page 

35-36 


Behaviors 

"General" 

Quantitativeness 

Scaled  Graphs,  Functions 

Supporting  Data 

fx~l  No  Validation 

|  |  Validation  with  Questionable  Results 
1  |  Validated 

Comments 


Reference 


Siegel,  A. I.,  et  al  (197?) 


Appropriate 

Yes 


Dependent  Variables 

Hunan  availability 


Independent  Variables 
Pace 

Men  per  shift 
Shift  length 
Level  of  aspiration 
Mental  load 
Leader's  expectation 


Page 

37-38 


Behaviors 

"General" 

Quantitativeness 

Scaled  Graphs, 

Functions 

Supporting  Data 

El 

No  Validation 

e 

EZ3 

Validation  with  Questionable  Results 

□ 

Validated 

Comments 


Reference 


Siegel,  A. I.,  et  al  (1978) 


Appropriate 

Yes 

Dependent  Variables 

Hunan  MTTR 

Independent  Variables 
Pace 

Mental  load 

Level  of  aspiration 

Leader's  expectation 


Page 


39-40 


Behaviors 

"General” 

Quantitativeness 

Scaled  Graphs,  Functions 

Supporting  Data 

fx]  No  Validation 

|  |  Validation  with  Questionable  Results 
|  |  Validated 

Comments 


Reference 


Siegel,  A. I.,  et  al  (1S78) 


I  Appropriate 

Yes 

i 

\  - 

•  Dependent  Variables 

|  Maximum  Stress 

* 

# 

* 

Independent  Variables 

Men  per  shift 
Pace 


Page 

41-42 


Behaviors 

"General" 


Quantitativen  ss 

Scaled  Graphs,  Functions 


Supporting  Data 

El 

No  Validation 

□ 

Validation  with  Questionable  Results 

□ 

Validated 

Comments 


Rjferencr 


Siegel,  A. I.,  et  al  (1978) 


Appropriate 

Yes 


Dependent  Variables 

Hazard  level 


L: dependent  Variables 
Pace 

Primary  Competence 
Shift  length 
Men  per  shift 


Page 

43-44 


sjipporting  Data 


|71  No  Validation 

1  |  Validation  with  Questionable  Results 
□  Validated 

Comments 


Reference 

Siegel,  A. I.,  et  al  (1978) 


Appropriate 

Yes 


Dependent  Variables 

Human  availability  and  manpower  utilization  tradeoff 


Independent  Variables 
Pace 

Shift  length 


Page 

45-46 

Behaviors 

"General” 

Quantitativeness 

Scaled  Graphs,  Functions 

Supporting  Data 


1x1  No  Validation 

1  1  Validation  with  Questionable  Results 
1  |  Validated 

Comments 


K-114 


/ 


rzyjrpcgggnm  »'t»  J  tv?  B««BuaLag»^.juagBE»i 


Reference 

Siegel,  A. I.,  Federman,  P.J.,  and  Welsand,  E.H.  Perceptual/psychomotor 
•  requirements  basic  to  performance  in  35  Air  Force  specialties.  Brooks 

AFB,  TX:  Air  Force  Human  Resources  Laboratory,  Technical  Report 
AF4RL-TR-80-26,  Contract  No.  F33615-78-C-0032  ADA03P39C1 


Appropriate 

Yes 


Dependent  Variables 


Independent  Variables 

13  abilities:  Control  precision  Perception  of  size  and  form. 

Manual  dexterity  Depth  perception 

Finger  dexterity 
Multilimb  coordination 
Rate  control  (tracking) 

Visual  speed  and  accuracy 
Visual  memory 
Position  memory 
Auditory  memory 
Clerical  perception 


Page 

26  and  29 

Behaviors 

"General" 

Quantitativeness 

Nominal 

Supporting  Data 


jxl  No  Validation 

□  Validation  with  Questionable  Results 

□  Validated 


Comments 

Munitions  maintenance  and  fire  protection  specialities 
Other  also  missile  electronic  equipment  spec.  §  other  support 
Radio  operator 


K— 115 


9 


Siegel,  A. I.,  et  al 


Appropriate 


Yes 


Dependent  Variables 

Judged  need  for  ability  in  weapons  mechanic 


Independent  Variables 


Finger  dexterity 
Visual  memory 
Visual  speed  and  accuracy 
Position  memory 


k 

S 

5 


k 

rl 

i.- 

t* 


V!“°  120 

1 

Behaviors 

S' 

see  IV 

i. 

s 

Quantitative ness 

i" 

?! 

Nominal 

fc 

i 

Supporting  Data 

* 

CD 

No  Validation 

\ 

□ 

Validation  with  Questionable  Results 

t 

* 

. 

□ 

Validated 

-• 

* 

t 

» 

Comments 

r> 

Judged  by  job  incumbents  AF 

K- 116 


*• 


9 


Reference 

Siegel,  A.J.,  et  ?1 


Appropriate 

Yes 

Dependent  Variables 

Judged  need  for  ability  in  LOM  25  missile  mechanic 


Independent  Variables 

Manual  dexterity 
Position  memory 


Page 


120 


Behaviors 

See  IV 

Quantitativeness 

Nominal 

Supporting  Data 

jY]  No  Validation 

H  Validation  with  Questionable  Results 
□  Validated 


Comments 


*  wEsssBBsar lsssssaaar 


Reference 


Siegel,  A. I.,  et  al 


Appropriate 

Yes 

Dependent  Variables 

Judged  need  for  ability  in  information  specialist 


Independent  Variables 

Visual  memory 
Clerical  perception 


Page 


121 


Behaviors  *■ 

See  IV 

Quantitativeness 

Nominal 

Supporting  Data 

j~X~l  No  Validation 

□  Validation  with  Qujstionable  Results 

□  Validated 

Comments 


;v 

t  $ 

fv 

3 

u 

>* 

‘s 


Appropriate 


Dependent  Variables 

Judged  need  for  ability  in  missile  electronic  equipment  specialist 


Independent  Variables 

Manual  dexterity 

b  ‘  V  1 

Syi 

k\.*i 

_ £i; 

Page 

121 

- 

g: 

Behaviors 

See  IV 

■\:k 

*-* 

Quantitativeness 

v> 

;  \>* 

Nominal 

* 

r*’j 

Supporting  Data 


j~X~]  No  Validation 

□  Validation  with  Questionable  Results 
j  [  Validated 


K-119 


Reference 


Siegel,  A. I.,  et  al 


Comments 


K— 120 


XAI 


Dependent  Variables 

Judged  need  for  abilities  in  missile  facilities  specialist 


Independent  Variables 


Finger  dexterity 
Position  memory 


Behaviors 


See  IV 


Quantitativeness 


Nominal 


Supporting  Data 


[FI  No  Validation 

i 

□  Validation  with  Questionable  Results 
|  |  Validated 


21 


Reference 


Siegel,  A. I.,  et  al 


Appropriate 


Dependent  Variables 

Judged  need  for  abilities  in  ground  radio  equipment  repair 


Independent  Variables 

Finger  dexterity 
Manual  dexterity 
Control  precision 
Visual  memory 
Visual  speed  and  accuracy 
Position  memory 


Page 


121 


Behaviors 

See  IV 

Quantitativeness 

Nominal 

Supporting  Data 

[x~|  No  Validation 

□  Validation  with  Questionable  Results 
PI  Validated 

Comments 


Reference 


Siegel,  A. I.,  et  al 


Appropriate 

Yes 

Dependent  Variables 

Judged  need  for  abilities  in  electrician 


Independent  Variables 

Finger  dexterity 
Manual  dexterity 
Vicual  memory 


Page  121 

Behaviors 

See  IV 

Quantitativeness 

Nominal 

Supporting  Data 

[%~1  No  Validation 

|  |  Validation  with  Questionable  Results 
□  Validated 

Comments 


5?  Consents 


K— 123 


^  ,'  f]p  %• 


VAirvyASMl'  KWJCJVJWKStPn  grgPBtmEtWTTCTrrrrc*  iaiiajmai»n**a.«mji*w  »■»■*» 


Reference  Siegel,  A. I.,  Fedcrman,  P.J.,  and  Sellman,  W.A.  A  survey  of  student 
measurement  and  course  evaluation  procedures  within  the  Air  Training 
Command,  Lowry  AFB,  CO:  Air  Force  Human  Resources  Laboratory, 

Technical  Report  AFHRL-TR-74-5,  July  1974,  Contract  No.  F41609-71-C-0075 
r  AD  786041. 


Appropriate 


Dependent  Variables 


Independent  Variables 


\ 

i 


i_ _ 

*  Page 

e 

* 


Behaviors 

"General" 


t;  Quantitativeness 

l\ 

f 


Supporting  Data 

HI 

No  Validation 

□ 

Validation  with  Questionable  Results 

□ 

Validated 

Comments 


Reference  Rouse,  W.B.  Problem  solving  performance  of  maintenance  trainees  in  a 


fault  diagnosis  task.  Hunan  Factors,  1979,  21  (2),  195-203. 


*<• 


s 

*- 

\ 

s 


Appropriate 

No 

Dependent  Variables 


v 

M 


I. 


Independent  Variables 

| 

I 

I 


Page 

f 

Behaviors 

"General" 

i _ 

T"i  Quantitativeness 


1 


Supporting  Data 

i 

[7~1  No  Validation 

□  Validation  with  Questionable  Results 
|fl  Validated 


v 
* , 

t'j 


Comments 


Reference 


Rouse,  W.B.  and  Rouse,  S.H.  Measures  of  complexity  of  fault  diagnosis 
-asks.  IEEE  Transactions  on  Systems,  Man,  and  Cybernetics,  1979,  SMC-9 
(11),  720-727. 


j  .  Appropriate 

Yes 

i  Dependent  Variables 

J  Complexity  of  a  fault  diagnosis  task 

t 

* 


Independent  Variables 

Information  metric 

Number  of  feasible  solutions  to  find  the  symptomatic  component 
Probability  of  finding  a  failure  when  testing  a  given  connection 


Page 

724 


Behaviors 

Seeing  implications  and  consequences,  logical  evaluation,  general  reasoning 


Quantitativeness 

Nominal,  Functions 


Supporting  Data 


. 

□ 

No  Validation 

1 

□ 

Validation  with  Questionable  Results 

V 

0 

Validated 

Comments 


t.->  .'!S~8ISU  V.WV-j — IL'l'..  V.1  .^.  .JJJi puji •*» : 


13 


Reference 


Rouse,  W.B.  A  model  of  human  decision  making  in  fault  diagnosis  tasks  that 
include  feedback  and  redundancy,  IEEE  Transactions  on  Systems,  i^an,  and 
Cybernetics.  1979,  SMC- 9  (4),  237-241. 


r 


Appropriate 


Dependent  Variables 

ffcunber  of  tests  to  solution 


Independent  Variables 

Psychological  distance 

Nature  of  the  network  under  fault  test:  presence  of  feedback 


Page 

Behaviors  Flexibility,  decision  making,  general  reasoning, 
and  consequences  , 

seeing  implications 

1 

j 

Quantitativeness  ! 

j 

Functions 

i 

i .  .  . . -  .  .  ..  .  .  . . . . 

Supporting  Data 

| 

|  |  No  Validation 

□  Validation  with  Questionable  Results 
|  |  Validated 


Comments 

Fuzzy  set  mod«l 

Feedback  use  is  subject  specific 


K-127 


xy 

Reference  Rouse,  W.ti.  A  model  of  human  decision  making  in  a  fault 
diagnosis  task.  IEEE  Transactions  on  Systems,  Man,  and 
Cybernetics,  1978,  SMC-QaTT  J57-35T: 


Appropriate 

Yes 


Dependent  Variables 

Number  of  tests  to  solution 


Independent  Variables 

Psychological  distance 


\ 


Page 

359 

Behaviors 

Decision  making,  foresight 

Quantitativeness 

Functions 

Supporting  Data 


D  No  Validation 

□  Validation  with  Questionable  Results 
HD  Validated 

Comments 

Model  presented 


K-128 


' > 71  JT' JT»JT'>'^jrT  V  maMriMik*  n*  -_M  -vjt 


Reference  Rouse,  W.B.  Problem  solving  performance  in  two  semester 
maintenance  trainees  in  two  fault  diagnosis  tas!:s.  Human 
Factors,  1979,  21  (5),  611-618. 


r 


Appropriate 

No 

Dependent  Variables 


Independent  Variables 


Supporting  Data 


[71  No  Validation 

□  Validation  with  Questionable  Results 

□  Validated 

Comments 


K— 129 


y  «jrif  ;— k-  x— KKjnttr  r*m 


Reference  Rouse,  W.B.  A  model  of  the  human  in  a  cognitive 

prediction  task.  IEEE  Transactions  on  Systems,  Man, 
and  Cybernetics,  SMC-3  (.5),  1.973,  473-477. 


Appropriate 


Dependent  Variables 


System  state  at  time  N 
Constants 

System  state  at  time  N  ♦  1 
Last  10  points 


System  state 

Location  of  a  point 

* 

1 

l 

Independent  Variables  ^ 

Behaviors  Visual  memory,  decision  making,  closure  abilities,  detection 


Quantitativeness 

Functions 


Supporting  Data 


Comments 


|  1  No  Validation 

□  Validation  with  Questionable  Results 
[%~1  Validated 


Slow  time  scale 

Cognitive  and  thought  factors  only 


K-130 


Reference  Baron,  S.  Kleinman,  D.L.,  Miller.,  D.C.,  Levison,  W.H.,  and  Elking,  J.I. 

Application  of  optimae  control  theory  to  the  prediction  of  human  performance 
in  a  complex  task.  Whight-Patterson  Air  Force  Base,  Ohio:  Air  Force 
Flight  Dynamics  Laboratory,  AFFDL-TR- 69-81,  March  1970,  F33615-68-C-1192. 


Appropriate 


Dependent  Variables 
Error 
Error  rate 
Control  input 


Observation-noise-ratios 


Independent  Variables 

Control  sensitivity 
Input  signal 

Single  axis  iris  full  task  perf. 
Faveal  iris  peripheral  vision 


Behaviors 


61,  63-66,  74,  76,  78-82,  85,  95 


Tracking 


Supporting  Data 


j  1  No  Validation 

□  Validation  with  Questionable  Results 
[x]  Validated 


Comments 


Optimal  scanning  model  [submodel  of  OCM)  is  described  on  pages  14-18. 
This  is  based  on  assumption  that  well-trained  human  operator  behaves  in 
an  optimal  manner  subject  to  his  inherent  limitations  and  constraints. 


K-131 


Reference  Baron,  S.  and  Kleinman,  D.L.  The  human  as  an  optimal 

controller  and  information  processor.  IEEE  Transactions  on 
'  Man-Machine  Systems,  MMS-10  (1) »  1969,  9-17. 


Appropriate 


Dependent  Variables 


Independent  Variables 


Supporting  Data 


pr~|  No  Validation 

1  1  Validation  with  Questionable  Results 
|  |  Validated 


Comments 


K-132 


•mam*  ww 


Reference  Levison,  W.H.,  Baron,  S.,  and  Kleinman,  D.L.  A  model  for  human 
controller  remnant.  IEEE  Transactions  on  Man-Machine  Systems, 
MMC-10,  Dec.  1979,  101-108. 


20  m 


Appropri ate 


Dependent  Variables 

Normalized  observation  noise  freq. 
Normalized  error  freq. 


Independent  Variables 


Mean- squared  input 
Vehicle  dynamics  (order  of  control) 
Input  bandwidth 
Input- injection  point 


K-133 


Reference  Kleinman,  DL.,  Baron,  S.,  and  Levison,  W.H.  An  optimal 
control  model  of  human  response.  Part  I:  Theory  and 
Validation,  Automatica,  1970,  6,  357-369. 


Appropriate 

No  -  older  article 
Dependent  Variables 


Independent  Variables 


Comments 


Good  model  specifications 


Reference  Baron,  S.,  Kleinman,  D.L.  and  II.  An  optimal 

control  model  of  human  response.  Part  il:  prediction  of 
human  performance  in  a  complex  task.  Automatica,  1970, 
6.  371-383. 

Appropriate 

No  -  older  article 
Dependent  Variables 

Independent  Variables 


Page 

Behaviors 

General 

Quantitativeness 

Supporting  Data 

PH  No  Validation 

□  Validation  with  Questionable  Results 

□  Validated 

Comments 


r.  3 <*stw«K«ww 


r 


Reference 


Kleinman,  DL.L.,  Baron,  S.,  and  Levison,  N.H.  A  control 
theoretic  approach  to  nanned-yehicle  systems  analysis. 
IEEE  Transactions  on  Automatic  Controls,  AC-16  (fi),  1971, 
824-832. 


Appropriate 


Yes 


Dependent  Variables 

u(t)  human  control  input  to  the  system 


Independent  Variables 


Vehilce  dynamics 
Display  output 
Observation  noise 
Time  delay 
Kalman  estimator 
Prediction 
Motor  noise 


Page 


827 


Behaviors 

Gross  positioning,  system  equalization 

Quantitativeness 

Functions 

Supporting  Data 

□ 

No  Validation 

□ 

Validation  with  Questionable  Results 

m 

Validated 

Comments 

p  830  "Of  course,  the  model  does  not  tell  us  whether  observed 

characteristics  of  the  human's  response  ...  are  implemented 
by  muscles  in  the  arm  or  in  the  head." 

Is  this  the  problem  of  identifiability? 


K-136 


VWWTV  r&i  uw;  -.-m.rxrs: 


Reference  Baron,  S.  Application  of  the  optimal  control  model 

*•  for  the  human  operator  to  reliability  assessment. 

IEEE  Transactions  on  Reliability,  R-22  (3),  1973,  157-164. 


Appropriate 


Yes 


Dependent  Variables 

Human  performance  reliability  on  a  particular  mission  segment 
RhW  Probability  that  a  given  task  will  be  correctly  executed  in 
some  increment  of  time. 

X  (t)  EX 


Independent  Variables 


yx)  *  Pr  {x  (t)  EX  I  stress}  ■ 


pdf  «  prob.  dist.  func. 


/ 


pdf  (x(t) (stress)  dx 
x(t)  EX 


Page 

161 

Behaviors 

System  equalization  abilities 

Quantitativeness 

Functions 

V 

:< 

{• 

y 

s 

,s 


Supporting  Data 


PH  Ho  Validation 

|  j  Validation  with  Questionable  Results 
j  |  Validated 


Comments 


Investigate  further 


K-137 


Reference  Phatak,  A.,  Weinert,  H.,  Segall,  I.,  and  Day,  C.N.  Identification 
of  a  modified  optimal  control  model  for  the  human  operator. 
Automatica,  1976,  L2,  31-41. 


Appropriate 

Yes 

Dependent  Variables 
Tracking 


Independent  Variables 

Operator  gain  yector 
Observation  noise  covariance 


Behaviors 


Tracking 


Quanti tativeness 

Functions 

Supporting  Data 

1  |  No  Validation 

PH  Validation  with  Questionable  Results 
□  Validated 

Comments 

Simplification  of  the  optimal  control  model 
The  intent  is  to  increase  the  identifiability  of  the  model 
parameters  it  seems  to  have  worked 


r 


Reference  Kessler,  K.M.  and  Phatak,  A.V.  Formulation  and  validation  of  a 
proportional-integral-derivative  (P-I-D)  structure  modified 
optimal  control  model  for  the  human  gunner  in  an  anti-aircraft 
artillerv  (AAA)  tracking  task.  IEEE  Conference  on  Decision  and 
Control/'lSth  Symposium  on  Adaptive  Processes,  1976,  1099-1105. 


Appropriate 


Yes 


i: 

I 


Dependent  Variables 

Tracking  error  over  time  (elevation,  azimuth) 


Independent  Variables 


Process  noise 
Target  trajectory 


I 


V 

S* 

,v 

s 


Page 


1104 


Behaviors 


System  equalization  abilities  (41-44),  tracking 


Quantitativeness 

Functions 


& 

I 


» 


Supporting  Data 


1  |  No  Validation 

□  Validation  with  Questionable  Results 
[71  Validated 


Comments 


K— 139 


*r  *H 


Reference  Sarma,  V.V.S.  and  Ramchord,  K.  Air  Fleet  and  Facility  Planning 
>'ia  optimal  control  models.  IEEE  Transactions  on  Systems,  Man 
and  Cybernetics,  1979,  SMC- 9  (3),  131-142. 


Appropriate 


Dependent  Variables 


}■ 

f 


i - 

Page 


Behaviors 

General 

Quantitativeness 

Supporting  Data 

[~^~]  No  Validation 

□  Validation  with  Questionable  Results 
1  j  Validated 

Comments 


Econometric  Model 


2£ 


Reference  Johannsen,  G.  and  Govindaraj,  T.  Optimal  control  model  predictions 
of  system  performance  and  attention  allocation  and  their  experimental 
validation  in  a  display  design  study.  IEEE  Transactions  on  Systems, 
Man,  and  Cybernetics,  SMC- 10  Q>3»  1980 


Appropriate 


Dependent  Variables 


Independent  Variables 


Page 


Behaviors 

General 


Quantitativeness 

Supporting  Data 

El 

No  Validation 

□ 

Validation  with  Questionable  Results 

□ 

Validated 

Comments 

OCM 


K— 141 


Reference  Baron,  S.  and  Levison,  W.H.  Display  analysis  with  the  optimal 

control  model  of  the  human  operator.  Human  Factors,  1977,  19  (S),  437-457. 


Appropriate 

Yes 


Dependent  Variables 

Displacement  noise  (tracking  error) 
Rate  noise  (tracking  rate  error) 


Independent  Variables 

Observation  noise 
Attention  allocation 
Display  variables 


Page 


441 


Behaviors 


Time  sharing;  system  equalization  abilities,  trccking 


Quantitativeness 

Functions 

Supporting  Data 

□ 

No  Validation 

□ 

Validation  with  Questionable  Results 

Validated 

Comments 

Only  aspects  of  the  model  relevant  to  display  analysis 


K— 142 


-  -I,  n,—  f— !  II  ■  — imi-n-rirm  n  , 


30 


Reference  Knoop,  P.A.  Survey  of  human  operator  modeling  techniques  for 
measurement  applications.  Wright-Patterson  AFB,  OH:  Air  Force 
Human  Resources  Laboratory,  Technical  Report  AFHRL-TR-78-35, 
July  1978.  ADA058327 

( 


Supporting  Data 


HI  No  Validation 

□  Validation  with  Questionable  Results 

□  Validated 

Comments 


K— 143 


Reference  Siegel,  A. I.,  Pfeiffer,  M.G.,  Kopstein,  F.,  Wolf,  J.J.,  and 
Ozkaptan,  H.  Human  Performance  in  Continuous  Operations: 
Volume  III.  Technical  documentation  ADA  088339. 


Appropriate 


Dependent  Variables 

Effectiveness  profile  by  combat  unit  type  and  by  performance  factor 


Independent  Variables 

Proficiency/speed  factor  by  unit  type 
Enemy/friendly  material  strength  ratio 
Enemy/friendly  personnel  strength  ratio 
Enemy/friendly  terrain  advantage 
Light  level 

Unit  replacement  conditions 

Time  of  day  that  battle  starts 

Hours  since  last  sleep  at  battlement 

Platoon  action  and  duration  for  each  combat  unit 


Behaviors 


Functions 


Quantitativeness 


Supporting  Data 


0  No  Validation 

|  [  Validation  with  Questionable  Results 
|  |  Validated 


Comments 
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■r*  -r 


Appropriate 


Yes 


Dependent  Variables 

Value  of  light  level 

Independent  Variables 

Light  conditions  (starlight  to  ciear,  sunny  day) 


Quantitativeness 


Nominal 


Supporting  Data 

HI  No  Validation 

|  [  Validation  with  Questionable  Results 

□  Validated 


Comments 


Reference  Siegel,  A. I,  et  al 


Appropriate  Ygs 


Dependent  Variables 

Effectiveness  of  performance  for  a  military  unit 


Independent  Variables 

Number  of  adverse  impacts  5 

Variabilil 

ly  of  impacts  ’ 

* 

— 

'  '  | 

Behaviors  t 

General 


Quantitativeness 

i 

Functions] 
Supporting  Data 


Comments 


fx~l  No  Validation 

□  Validation  with  Questionable  Results 
|  |  Validated 


K- 146 


40 


Reference  Siegel,  A. I.  et  ai 


Appropriate 

Yes 

Dependent  Variables 

Effectiveness  of  a  unit 


Independent  Variables 

Fatigue  level 

Light  level 

Stress  level 

Phase  of  diurnal  rhythm 

Regression  model 


Page 

58 

Bel  jviors 

General 

Qusntitativeness 

Functions 

Supporting  Data 

[71  No  Validation 

[  [  Validation  with  Questionable  Results 
[  [  Validated 


Comments 


Reference  Siegel,  A. I.,  Fischl,  M.A.,  and  MacPherson,  D.  The  analytic 
profile  system  CAPS)  for  evaluating  visual  displays.  Human 
Factors,  1975,  17_  (3),  278-288. 

Appropriate  Nq 
Dependent  Variables 

Independent  Varia .les 


Comments 


|~>T1  No  Validation 

[  |  Validation  with  Questionable  Results 
□  Validated 


Reference  Siegel,  A. I.  and  Bergman,  B.A.  A  job  learning  approach 

to  performance  prediction.  Personnel  Prycholcgy,  197S,  25,  325-339. 


v« 


>  Appropriate 

;  no 


Dependent  Variables 


£ 


Independent  Variables 


L-> 

.V 


Page 


Behaviors 


General 


Quantitativeness 


Supporting  Data 


in  No  Validation 

n  Validation  with  Questionable  Results 
□  Validated 


as~  <■; 

W.\ 
3a 


Comments 


Miniature  job  training 


K-149 


Involved  air-to-ground  rather  than  ground-to-air  detection. 

Presents  6  models  of  air-to-ground  target  acquisition 

Author  suggests  that  there  is  limited  evidence  of  overall  validation  esp. 
with  field  data. 


Comments 


Reference  Greening,  C.P.  and  Wyman,  M.J.  Experimental  evaluation 

of  a  visual  detection  model.  Human  Factors,  1970,  1_2  (5), 
435-455. 


Appropriate 


Dependent  Variables 

Cumulative  probability  of  having  recognized  a  target  by  a  certain 
point  in  the  approach 


Independent  Variables 

i 

Probability  of  looking  at  the  target  in  one  glimpse 

Available  resolution 

Obj  ect/background  contrast 

Sky/ground  luminance  ratio 

Aircraft  altitude  above  target 

Meteorological  range  (visibility) 

Slant  range 

Threshold  contrast  ratio 
Target  height/wiHth/depth 
Horizontal  range  to  target 

Humber  of  linear  resolution  elements  to  resolve  th3  target 
Page 


Behaviors 

General 


Quantitativeness 


Supporting  Data 

j  |  Ho  Validation 

f71  Validation  with  Questionable  Results 
!  □  Validated 

Comments 

Identification  problem  unsolved 
Underlying  neural  mechanisms  not  considered 
See  also  #34 


K-151 


■  Reference  Greening,  C.P.  Target  acquisition  model  evaluation:  final  summary 

report.  China  Lake,  CA:  Naval  Weapons  Center,  Technical  Report 

i  NWC  TP  5536,  1973,  Contract  No.  N00123-73-C-0250.  AD  913918L 

» 

*  / 

« 

i 


f  Appropriate 

p 

p 


No 


i 

•  Dependent  Variables 

J  Air-to-ground  target  acquisition 

i 


Independent  Variables 

Models:  VISTRAC 

FRANKLIN  8  WHITTENBURG 

DETECT  II  and  III 

CORNELL  AERO  LAB  -  RYLL 

MARSAM  II 

SHAPE 

GRC  (A5B) 

BOEING 

AUTONETICS 

N.A.  ROCKWELL  -  COLUMBUS 

SRI  CRESS/SCREEN 

VISTARAQ 

RAND 

NVJ 

FLAG 

Page 


Behaviors 

Detection,  identification 


-  Quantitativeness 


Supporting  Data 


m  No  Validation 

|  1  Validation  with  Questionable  Results 
|  j  Validated 


Comments 

Air-to-ground 

f4ich  info,  but  snould  be  more  clearly  presented  in  later 
Greening  articles 


K-152 


I 


Reference  Greening,  C.P.  Modeling  visual  target  acquisition:  Inclusion  of 
certain  psychological  variables.  Chine  Lake,  CA:  Naval  Weapons 
Center  Technical  Report  NWC  TP  5690,  August  1974,  Contract  Noc 
NOO-i  23-74-C-0236.  AD923266. 


Appropriate 


Dependent  Variables 


Independent  Variables 


Behaviors 


General 


Quantitativeness 


Supporting  Data 


|x~1  No  Validation 

□  Validation  with  Questionable  Results 
j  1  Validated 


Comments 


Air  to  ground  target  acquisition 
Autonetics  model 


K-153 


1 


Reference 


Bloomfield,  J.R.  Peripheral  acuity  with  complex  stimuli 
at  two  viewing  distances.  In  NATO  AGARD  Conference  Proceedings 
No.  100,  AGARD  CP-100,  Air  to  ground  target  acquisition,  Nov.  1972, 
Neuilly-Sur.  Seine,  France,  AD755082 


Appropriate 

Yes 

Dependent  Variables 

Minimum  perceptible  visual  angle 


|  Independent  Variables 

*•  Eccentricity  from  fovea 


Behaviors 


Detection 


Quantitativeness 

Scaled  Graphs 


Supporting  Data 


HD  No  Validation 

|  |  Validation  with  Questionable  Results 
|  |  Validated 


Comments 
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Reference 


Bloomfield,  J.R.  (1972) 


Appropriate 

Yes 


•  Dependent  Variables 

l 

j  Minimum  perceptible  target-background  difference  (minutes  of  angle) 


Independent  Variables 

Eccentricity 


I 


i 

Behaviors 

Detection 

Quantitativeness 

r 

Scaled  Graphs 

Supporting  Data 

D 

No  Validation 

; 

□ 

Validation  with  Questionable  Results 

,► 

r 

□ 

Validated 

Comments 


K-155 


Reference  Bloomfield,  J.R.  (1972) 


38 


Appropriate 

Yes 


Dependent  Variables 

Variations  in  viewing  distance  h?»ve  no  effect  on  target 
acquisition  or  visual  search 


Independent  Variables 

Providing  that: 

a)  the  search  display  has  angular  dimensions  of  9°  or  more; 

b)  viewing  distance  is  greater  than  two  feet;  and 

c)  viewing  distance  is  not  so  great  as  to  preclude  target 

resolution  then  -*■ 


Page 


B6-9 


Behaviors 

General 

Quantitativeness 


Supporting  Data 

PH  No  Validation 

I  |  Validation  with  Questionable  Results 
□  Validated 

Comments 

As  long  as  visual  angle  is  constant,  viewing  distance  doesn't  matter. 


K- 156 


Reference  AGARD  Air  to  ground  target  acquisition.  AGAF")  Conference 

Proceedings  No.  100,  AGARD  CP-100,  Neuilly-Sur-Seine,  France, 
November  1972.  AD7S5082 


Appropriate 

Medium 

Dependent  Variables 

Peripheral  acuity  (minimum  perceptible  visual  angle) 

Independent  Variables 

Eccentricity  from  favea 


Page  62 

Behaviors 

Detection 

Quantitativeness 

Supporting  Data 

El  No  Validation 

□  Validation  with  Questionable  Results 
[  |  Validated 


Comments 


»TW  <■»  mxn  t  *  A.- ,nw.  i--  « 


Reference 


,  Jones,  D.B.,  Freitag,  M. ,  and  Collyer,  S.C.  Air-to-ground  target 

acquisition  source  bock:  a  review  of  the  literature.  Arlington,  VA: 
Office  of  Naval  Research,  Code  455,  September  1974,  Contract  No. 
r  N00014-72-C-0389.  ADA015079. 


Appropriate 

yes 

Dependent  Variables 


Independent  Variables 


Large  amounts  of  data  on: 

Properties  of  the  visual  system 
Target  and  environmental  factors 
Atmospheric  conditions 
Visibility  parameters 
Visual  search 
Models 

Imagery  parameters 


Page 

Behaviors  ' 

Quantitativeness 

Supporting  Data 

[xj  No  Validation 

□  Validation  with  Questionable  Results 

□  Validated 

Comments 

This  is  an  experimental  psychology  text  on  visual  detection.  154  pages. 
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Reference 

Jones,  D.B.,  et  al. ,  1974. 


Appropriate 

Dependent  Variables 

Log  threshold  contract 
Search  time 


Independent  Variables 
Log  target  area 

Contrast  and  size  difference  of  targets  and  distractors 


Page 

Behaviors 

Quantitativeness 

Supporting  Data 

No  Validation 

Validation  with  Questionable  Results 
Validated 

Comments 

An  example  of  the  contents  of  this  document. 


HI 

□ 

□ 


Reference 

Gordon,  J.J.,  Fean,  C.R.,  and  Church,  P.V.  Visual  detection  of  low 
altitude  aircraft  (summer).  Bureau  of  Ships;  Technical  Report  No. 
NS-7.14-100,  November  1961,  Contract  No.  N00024-68-C-1100.  AD512783. 


Appropriate 

No 


Dependent  Variables 


Independent  Variables 


* 


Page 


Behaviors 


Quantitativeness 


Supporting  Datkl 


Comments 


pH  No  Validation 

1  |  Validation  with  Questionable  Results 
|  |  Validated 


Air-to-air  detection,  B-52  target,  500  ft. 

Motion  detection,  rather  than  shape  detection,  will  be  the  cue. 
Recon.  at  20,000,  5000,  and  3000  ft. 
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45 


Reference 


41 


Camden,  R.S.  Real-time  air  defense  radar  display:  operator  console 
simulation.  Aberdeen  Proving  Ground,  M.D. :  0.  S.  Army  Human  Engineering 
Laboratory,  Technical  Memorandum  23-76,  June  1976.  ADA028217. 


Appropriate 


Dependent  Variables 


Independent  Variables 


Behaviors 


Quanti tativenes  s 


Supporting  Data 


|~X]  No  Validation 

□  Validation  with  Questionable  Results 
|  |  Validated 


Comments 


An  operator  simulation  of  the  SAM-D  Air  Defense  System  should  exist. 
These  are  the  programs  to  assess  the  man-machine  interface. 


K-161 
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Reference 

Hilgendorf,  R.  and  Milenski,  J.  SEEKVAL  Project  IA1:  effects  of  target 
number  and  clutter  on  dynamic  target  acquisition.  Wright-Patterson  AFB,  OH: 
AMRL,  AMD,  Technical  Report  AMRL-TR-74-4,  January  1976,  Contract  No. 

F33615-7  3-C-4106 .  ADA024166 


Appropriate 

No 


Dependent  Variables 


Independent  Variables 


t'*r* 


p  t 


i  i 


Behaviors 

1 w?**. 

I...  «“  '•* 

Quantitativeness 

'.-.V 

f-  * 

Supporting  Data 

|Y]  No  Validation 

£5 

|  1  Validation  with  Questionable  Results 

Q  Validated 

r'\*[ 

• 

Comments 

•-> 

* 

Air  to  ground 

detection. 

*  .*> 

r,s£ 

„  p  * 

K-162 


Comments 


Appropriate 

Tee 

Dependent  Variables 

Sleep  loss  decrement  in  performance. 

Independent  Variables 

Work  schedules  aost  vulnerable  to  performance  impairment  by  sleep  loss. 


Page 

1,  1,  14-16 
Behaviors 

Quantitativeness 

Nominal 

Supporting  Data 

ITl  No  Validation 

□  Validation  with  Questionable  Results 

□  Validated 

Comments 


K-164 


Reference 

Woodward,  D.P.,  at  al.,  1974. 


Appropriate 

Yea 


Dependent  Variables 

Performance  impairment 


Independent  Variables 


Aaount  of  sleep  lose  required  to  im; 

*• 


tir  performance 

l ' 


Page 

2 

Behaviors 

i 

Quantitativeness 

Nominal 

Supporting  Data 

fxl  Ho  Validation 

|  |  Validation  with  Questionable  Results 
□  Validated 

Comments 


Reference 


Woodward,  D.P.,  et  el.,  1974. 


Appropriate 

Tti 

Dependent  Variables 

Types  of  performance  impairment  most  likely  from  Bleep  loss 

Independent  Variables 


Behavi.cn 

Quantitativeness 

Nominal 

Supporting  Data 

□  No  Validation 

j  |  Validation  with  Questionable  Results 
|  j  Validated 

Comments 


Reference 


Woodward,  D.P.,  at  al.,  1974. 

Appropriate 

Dependent  Variables 

Independent  Variables 

Procedures  for  reducing  iapairaent  risks  in  continuous  operations. 


Page 

3 

Behaviors 

Quantitativeness 

Moainal 

Supporting  Data 

in  No  Validation 

I  1  Validation  with  Questionable  Results 
□  Validated 

Coaaents 


Reference 

Woodward,  D.P.,  at  al.,  1974. 


Quant i tativeness 
Soolnal 
Supporting  Data 


fx]  No  Validation 

H  Validation  with  Questionable  Results 
n  Validated 


Cossaents 


K-168 


- . . 


Reference 


Woodward,  D.P.,  et  al.t  1974. 


Appropriate 

Yes 

Dependent  Variables 

Recommended  hours  of  recovery 


Independent  Variables 

Cumulative  hours  of  sleep  loss 


Page 

4 

Behaviors 

Quantitativeness 

Scaled  Graphs 
Supporting  Data 

fTI  No  Validation 

|  j  Validation  with  Questionable  Results 
|  |  Validated 

Comments 


K-169 


Reference 


Woodward,  D.P.,  eC  al.,  1974. 


Appropriate 

Yes 


Dependent  Variables 

Sleep  loss  decrement  in  performance 


Independent  Variables 
Task  duration 


Page 

9-13 

. . g""  * . "  . — 

Behaviors 


Quantitativeness 
Nominal 
Supporting  Data 

fxl  No  Validation 

□  Validation  with  Questionable  Results 
|  |  Validated 

Comments 


TIT-If-". 


t-’f’ 


v, ».  yr.vj-.Kr. 


^  r*  it  reromi  vwtt*  »»nw 

4j 


Reference 


Wright,  A.U.  The  performance  of  ground  observers  in  detecting, 
recognizing,  and  estimating  range  to  low-altitude  aircraft.  Fort  Bliss,  TX: 
Human  Resources  Research  Office,  Technical  Report  66-19,  December  1966 j 
Contract  No.  DA-44-188-ARO-2.  AD645537. 


Appropriate 

Yes 


Dependent  Variables 

Range  of  incoming  A/C  when  detected 


Independent  Variables 

Aircraft  class  (jet,  propeller) 

Visual  aiding  (none,  unaided  detection  with  aided  recognition, 
aided  detection  and  recognition) 

Observer  offset  (0,650,1400me.) 


Page 

9 

Behaviors 

detection 

Quantitativeness 

Table  X 

Supporting  Data 

□ 

No  Validation 

□ 

Validation  with  Questionable  Results 

□ 

Validated 

Comments 


Reference 


Wright  (1966) 


Appropriate 

Yes 


Dependent  Variable* 

Range  of  incoming  A/C  when  tentatively  recognized 
Range  of  incoming  A/C  when  positively  recognized 


Independent  Variables 

1  | 

Aircraft  class  (jet,  propeller) 

Visual  aiding  (none,  unaided  detection  with  aided  recognition,  aided 
I  detection  and  recognition) 

Ol|s,erver  offset  (0,650,1400  meters) 


Page 


Behaviors 

discrimination 

Quantitativeness 

Table 


Supporting  Data 

□  No  Validation 

□  Validation  with  Questionable  Results 
[7]  Validated 

I 


Comments 


Reference 


Wright  (1966) 


Appropriate 

Yes 

Dependent  Variables 

Probability  of  detecting  incoming  A/  C 
Probability  of  tentatively  recognizing  incoming  A/C 
Probability  of  positively  recognizing  incoming  A/C 


Independent  Variables 

Range  (0  to  20,000  aeters) 


■< 


Page 

12 


Behaviors 

detection 

discrimination 

Quantitativeness 
Table  1 

_ Scaled  Graphs _ 

Supporting  Data 

n  No  Validation 

□  Validation  with  Questionable  Results 

□  Validated 


Comments 


V 


K-173 


45  t 

Reference 

Wright  (1966) 

W 

Appropriate 

» 

Yes 

t'v  .  . 

£ 

Dependent  Variables 

i 

Probability  of  detecting  Incoming  A/C 

r 

1 

Independent  Variables 

Range  (0  to  20,000  meters) 

Type  A/C  (het  A/C,  propeller  A/C,  helicopter  A/C) 

g 

1 

l 

! 

E 

Page 

1 

13 

► 

J 

Behaviors 

I 

detection 

f 

kif 

Quantitativeness 

•  *{ 

i  ! 

Scaled  Graphs 

I 

Supporting  Data 

# 

► 

1  |  No  Validation 

i 

f 

> 

i 

|  |  Validation  with  Questionable  Results 

i 

HR  Validated 

% 

t 

* 

'  I 

S imments 

i 

V 

» 

<k 

K-174 

i 

l 

1  ■  '  '  j 

i 

< 

ha  ha.ha  ».-.*  x*.-  *■  *=w«a » -, 


Reference 


Wright  (1966) 


Appropriate 


Dependent  Variables 


Probability  of  tentatively  recognizing  incoming  A/C 
Probability  of  positively  recognizing  incoming  A/C 


Independent  Variables 


Range  (0  to  20,000  meters) 

Type  A/C  (jet  A/C,  propeller  A/C,  helicopters) 


Behaviors 

discrimination 

Quantitativeness 

Scaled  Graphs 

Supporting  Data 


|  |  No  Validation 

!~1  Validation  with  Questionable  Results 
ril  Validated 


Comments 


K-175 


Reference 


Wright  (1966) 


Appropriate 

Yes 

Dependent  Variables 

Probability  of  detecting  incoming  A/C 
Probability  of  tentatively  recognizing  incoming  A/C 
Probability  of  positively  recognizing  incoming  A/C 

Independent  Variables 

Range  (0  to  20,000  meters) 

Observer  offset  (0l  650,  1400  meters) 


Behaviors 


detection,  discrimination 


Quantitativeness 

Scaled  Graphs 


Supporting  Data 


1  |  No  Validation 

Fj  Validation  with  Questionable  Results 
a  Validated 


Appropriate 

Yes 

Dependent  Variables 

Probability  of  detecting  incoming  A/C 
Probability  of  tentatively  recognizing  incoming  A/C 
j  Probability  of  positively  recognizing  incoming  A/C 


Independent  Variables 

j 

j  Range  (0  to  20,000  meters) 

Type  A/C  (F-4C,  F-100,  T-33) 


Page 

16 

Behaviors 

detection  discrimination 

Quantitativeness 

Scaled  Graphs 

Supporting  Data 

[3]  No  Validation 

|  □  Validation  with  Questionable  Results 

03  Validated 

Comments 


Reference 


Wright  (1966) 


Appropriat  ■> 

Yes 


Dependent  Variables 

Probability  of  detecting  incoming  A/C 
Probability  of  tentatively  recognizing  incoming  A/C 
Probability  of  positively  recognizing  incoming  A/C 


Independent  Variables 

Range  (0  to  20,000  meters) 

Type  rotary-wing  A/C  (4-1A,  4-6A,  0-1A,  0 


Page 

17 


Behaviors 

detection 

discrimination 

Quantitativeness 

Scaled  Graphs 


Supporting  Data 

n  No  Validation 

|  |  Validation  with  Questionable  Results 

[T]  Validated 


Concents 


Reference 


Wright  (1966) 


Appropriate 

Yes 

Dependent  Variables 

Estimated  range  of  incoming  A/C  when  detected 

Estimated  range  of  incoming  A/C  when  tentatively  recognized 

Estimated  range  of  incoming  A/C  when  positively  recognized 


Independent  Variables 

Aircraft  class  (jet,  propeller,  helicopter) 


Behaviors 

detection,  discrimination,  spatial  orientation 


Comments 


]  |  No  Validation 

□  Validation  with  Questionable  Results 
H  Validated 


J, 


Appropriate 

Yes 


Dependent  Variables 

Estimated  range  of  incoming  A /C  when  detected 

Estimated  range  of  incoming  A/C  when  tentatively  recognized 

Estimated  range  of  incoming  A/C  when  positively  recognized 


Independent  Variables 

Visual  aiding  (none,  binoculars  for  recog.,  binoculars  for  det.  and  rec.) 
Observer  offset  (none,  650,  1400  meters) 


Behaviors 

detection,  discrimination,  spatial  orientation 

Quantitativeness 

Table 


Supporting  Data 


□  No  Validation 

□  Validation  with  Questionable  Results 
|~xl  Validated 


Comment; 


K-180 


Reference 


Wright  (1966) 


45 


Appropriate 

Yes 

Dependent  Variables 

Percent  range  estimation  error  of  incoming  A/C  when  detected 

Percent  range  estimation  error  of  incoming  A/C  when  tentatively  recognized 

Percent  range  estimation  error  of  incoming  A/C  when  positively  recognized 


Independent  Variables 

Type  A/C  (jet  propeller,  helicopter) 


Page 

21 

Behaviors 

detection,  discrimination,  spatial  abilities 

Quantitativeness 

Table 

Supporting  Data 

|  |  No  Validation 

□  Validation  with  Questionable  Results 
fig  Validated 


Comments 


Reference 


Wright  (1966) 


Appropriate 

Yes 


Dependent  Variables 

Percent  range  estimation  error  of  incoming  A/C  when  detected 

Percent  range  estimation  error  of  incoming  A/C  when  tentatively  recognized 

Percent  range  estimation  error  of  incoming  A/C  when  positively  recognized 


Independent  Variables 

Visual  aiding  (none,  binoculars  for  recog.,  binoculars  for  det.  end  recog.) 
Observer  offset  (none,  650,  1400  meters) 


> .  - 


Page 

22 


Behaviors 

detection,  discrimination,  spatial  abilities 


Quantitativeness 

Table 


Supporting  Data 


Comments 


|  j  No  Validation 

1  |  Validation  with  Questionable  Results 

~x|  Validated 


Reference 


vi'tym  r»T^T<TnTrTrrpTrr  n  w 
46 


Baldwin,  R.D.  Relationship  between  recognition  range  and  the  size,  aspect 
angle,  and  color  of  aircraft,  Washington,  D.C.:  Human  Resources  Research 
Organization,  Technical  Report  73-2,  February  1973,  Contract  No. 

DAHC  19-73-C-0004.  AD758870. 


Appropriate 

Yes 

Dependent  Variables 

Recognition  range  to  model  A/C 


Independent  Variables 

Type  A/C  (Af-IE,  F-84,  F-100,  F-102,  Mirage,  MIG-15,  Futer,  M.G-21, 
B-66,  B-57,  Flashlight,  Frebar,  Beagle) 

Aspect  angle  (0*-0#,  15*-45*,  IS’^O®,  10*-15#,  45*-35',  O'-SO0) 
Iclimb-heaJing] 


1  1 

Page 

8 

«" 

I 

Behaviors 

**■  — 

discrimination 

V 
►  ) 

Quantitativeness 

V 

Supporting  Data 

□ 

No  Validation 

5 

K 

□ 

Validation  with  Questionable  Results 

f. 

f: 

s 

Validated 

K  Comments 


Used  models  supported  on  boom  mounted  on  truck — not  realistic  since  truck 
gave  additional  cues,  etc. 


K-183 


Reference 


Baldwin  (1973) 

Appropriate 

Yea 

Dependent  Variables 

Recognition  range  to  model  A/C 

Independent  Variables 

Type  A/C  (AF-1E,  F-100,  F-102,  Mirage,  B-66,  Beagle) 
Color  (grey,  silver) 


Behaviors 

discrimination 


Quantitativeness 

Table 


Supporting  Data 


Comments 


n  No  Validation 

I  |  Validation  with  Questionable  Results 


Validated 


See  head  p=»ge  for  this  articl' 


Reference 


Baldwin  (1973) 


Dependent  Variables 

Percent  error  in  recognizing  A/C  models. 


Independent  Variables 


Aspect  angle  [climb-heading]  (0*-0\  10°-15\  15*-20#,  15*-45°,  45*-35B,  0B-90B) 


Page 

10 


Comments 


K-I85 


46 

Reference 

Baldwin  (1973) 


Appropriate 

Yes 

Dependent  Variables 

A/C  size  at  mean  recognition  range. 

Independent  Variables 

Type  A/C 
Aspect  angle 


Page 

11 

Behaviors 

jj ;  disc  rimination 

ji _ i 

Quantitativeness  I 

| 

I  Table 

Supporting  Data 

|  |  No  Validation 

]  |  Validation  with  Questionable  Results 

jT)  Validated 

Comments 

Used  model  A/C 


K-  1.86 


'  >rrm  v-v1  y?.  r:  yrcrrrrnr:  nn^  <: » 


r^“ 


Reference 

Baldwin  (1973) 


Appropriate 

Yes 


Dependent  Variables 

Observer  reliability  for  recognizing  A/C 


Independent  Variables 

A/C  aspect  angle 


Page 

14 

Behaviors 

human  reliability 

Quantitativeness 

Table 

Supporting  Data 

□ 

No  Validation 

□ 

Validation  with  Questionable  Results 

H 

Validated 

Comments 

Ised  A/C  models 


K-187 


T 


i'.'-V-.'"  V'".  3T-- 


'"WT.”  ’  X-  -i  ■  "a 


Reference 


Baldwin  (1973) 


Appropriate 

Yes 


Depenaent  Variables 

Mean  and  SO  of  recognition  ranges  to  model  A/C 


Independent  Variables 

Aspect  angle 
Type  A/ C 


Behaviors 

discrimination 


Supporting  Data 


f  |  No  Validation 

j  |  Validation  with  Questionable  Results 


Validated 


*  sO 

r  <r 


Reference 


Baldwin,  R.D. ,  Frederickson,  E.W, ,  and  Hackerson,  E.C.  Aircraft 
recognition  performance  of  crew  chiefs  with  and  without  forward  observers. 
Washington,  D.C.:  Human  Resources  Research  Organization,  Technical  Report 
70-12,  August  1970,  Contract  No.  DAHC  19-70-C-0012.  AD714-*13. 


Appropriate 

Yes 


Dependent  Variables 

Percent  correct  recognition  of  incoming  A/C  [real  &  models] 


Independent  Variables 

Team  (crew,  single  crew  chief,  single  observer) 
Range  (0  to  20,000  meters) 


Page 

14 

» 

Behaviors 

*  '  i 

discrimination 

.  _  _  _  i 

Quantitativeness 

Scaled  Graphs 

i 

Supporting  Data 

i 

i 

, _ .  i 

I |  No  Validation  i 

|  |  Validation  with  Questionable  Results  1 

1 

X 

|  Validated  i 

-  - - - - -  .  —  -  -  . —  -  --  . -  -  .  - . —  » 

Comments 


K-185 


.  rj*  rju  r  j*  r. 


*Vi-4  A  i 


47 


Reference 


Baldwin,  et  al.  (1970) 


Appropriate 

Yes 

Dependent  Variables 

Remaining  engagement  time  (time  between  crew  chief's  positive  recognition 
Judgment  and  A/C  arrival  at  simulated  weapon's  crossover  point) 


Independent  Variables 

Crew  vs.  single  observer 
Observer  offset  (0,  90°,  2500m) 


l 

i 


j? 


( 

► 


i 


Page 

15-16 


Behaviors  ’ ' 

discrimination 

r 


— f 

Quantitativeness  t 

Table  j 

Supporting  Data 

j 

n 

No  Validation 

i 

□ 

Validation  with  Questionable  Results 

Validated 

Comments 


K-190 


Reference 


Baldwin,  et  al.  (1970) 


Appropriate 

Yea 

Dependent  Variables 

Communication  ucore  (sum  ci  seal-*  va.'vve  of  sequence  codes  during 
observations) 

Independent  Variables 
Crew 

Plight  offset  (0*,  90* ,  2500m) 


Quantitativeness 

Table 


Supporting  Dita 

□  No  Validation 

HI  Validation  with  Questionable  Results 
[T]  Validated 

Comments 


jj®r!% 

*5* 

• » 

,  W* 


Reference 

Baldwin,  et  al.  (1970) 


Appropriate 

Yes 


Dependent  Variables 

Percentage  recognition  accuracy 


Independent  Variables 
Crew 


Observer  (chief  alone,  chief  in  crew,  forward  observer) 


Page 


20 


is 

pi 


Behaviors 

discrimination 


Quantitativeness 

Table 


Supporting  Data 


n  No  Validation 

H  Validation  with  Questionable  Results 
JT|  Validated 


Comments 


K-192 


i 


Reference 


Baldwin,  R.D. ,  Cliborn,  R.C. ,  and  Fosicett,  R.  J.  ihc  acquisition  and 
retention  of  visual  aircraft  recognition  e’:ix!s.  Arlington,  VA:  Amy 
Research  Institute,  ARI  Technical  Report  TR-76-M ,  0  ntract  No. 
DAH-19-75-C-0020. 


Quantitativeness 


Supporting  Data 

0  No  Validation 

□  Validation  with  Questlonahle  Results 

□  Validated 

Co  assents 


K-193 


Reference 


Baldwin,  R.D.  Capabilities  of  ground  observers  to  locate,  recognize,  and 
estimate  distance  of  low-flying  aircraft.  Alexandria,  VA:  Human  Resources 
Research  Oiganization,  Technical  Report  73-8,  March  1973,  DAdC  19-73-C~OOQ< . 
AD758873- 

Appropriate 

Yes 

Dependent  Variables 

Probability  of  detection 


Independent  Variables 

Range  (0  to  20,000  meters) 


Page 

8-9 

Behaviors 

detection 

Quantitativeness 

Scaled  Graphs 

Supporting  Data 

Q  No  Validation 

|  1  Validation  with  Questionable  Results 
QtJ  Validated 


Comments 


R«feT3t»C6 


Teichner,  W.H.  and  Mocharnuk,  J.B,  Visual  search  lor  complex  rargeta. 
Human  Factors,  1979,  21(3),  259-275. 


Appropriate 

High 


Dependent  Variables 

Search  time 
Time  per  stimulus 


Independent  Variables 

!  Half  number. of  stimuli 
I  1,2,3  dimensional  search 


Behaviors 


Perceptual  speed 


Quantitativeness 


Scaled  Graphs 


Supporting  Data 


PI  No  Validation 

H  Validation  with  Questionable  Results 
[xj  Validated 


Comments 


Support  for  Teichner' s  two-strategy  approach. 


K-195 


Reference 


Telchner,  W.H. ,  et  al,  (1979) 

< 

Appropriate 

High 

Dependent  Variables 

Total  information 

Independent  Variables 

Information  In  each  dimension 


Page 

268 

Behaviors 

Perceptual  speed 

Quantitativeness 

Functions 

Supporting  Data 


Comments 


Q  No  Validation 

1  !  Validation  with  Questionable  Results 
Fx]  Validated 


K-l  96 


Reference 


Teichr.er,  W.  II.  and  Krebs,  M.  J.  Laws  of  visual  choice  reaction  time. 
?syctc logical  Review,  1974,  81(1),  75-98. 


Appropriate 

High 

Dependent  Variables 
Choice  RT 


Independent  ariables 

Log 2  number  of  alternatives 
Low  practice 
Light/dlglt  stimuli 
Key/voice  responses 


Page 

81 


Behaviors 

Reaction  time  (45) 


Quantitativeness 

Scaled  Graphs 

Supporting  Data 

1  |  No  Validation 

|  1  Validation  with  Questionable  Results 
[~xl  Validated 


Comments 


Reference 


51 


r 

Appropriate 

High 

Dependent  Variables 

Choice  reaction  time 


Independent  Variables 

Stimulus  probability 
Varying  S  -  R  tasks 
Critical  signal  probability 


i 

/ 


I 


Page 

87,  89 


Behaviors 

Reaction  time 

Quantitativeness 

Scaled  Graphs 

Supporting  Data 

□ 

No  Validation 

□ 

Validation  with  Questionable  Results 

E? 

Validated 

K— 199 


Comments 


.Reference 


Teichner,  W.H. ,  et  al.  (1574) 


Appropriate 

High 

Dependent  Variables 

Choice  reaction  time 


Independent  Variables 

Log^Q  number  of  trials  (practice) 
Digit~key/light~key 


Page 

P2,  8* 


Behaviors 

Reaction  time 

(45) 

Quantitativeness 

Scaled  Graphs 

Functions 

Supporting  Data 

□ 

No  Validation 

□ 

Validation  with  Questionable  Results 

13 

Validated 

Comments 


K-200 


Reference 


Teichner,  W.  H. ,  et  al.  (197*0 


Appropriate 

-4 

High 

#. 

■x 

Dependent  Variables 

Choice  reaction  time 

V 

ft 

i 

1 

Independent  Variables 

1 

f 

L°g2  number  of  alternatives 

4- 

#  practice  trials 

■s 

I 


Page 

86 

Behaviors 

Reaction  time  (U5) 


Quantitativeness 

Scaled  Graphs 


Supporting  Data 

[~x|  No  Validation 

I  |  Validation  with  Questionable  Results 
|  |  Validated 


Comments 

hr,  practice  increases,  TR  becomes  constant  as  number  of  stimuli  increases. 
In  othcr  words,  Hick's  Law  and  the  single  channel  hypothesis  vanish  at  high 
levels  of  practice. 


| 

4, 

4 


i 

j 


% 


I 

5 


K-201 


Reference 


52 


Barber,  P.  Visual  Search  and  Number  of  Stimuli  Re-examined. 
Psychological  Bulletin,  89  (1),  176  -  132 


Appropriate 

Slight 


Dependent  Variables 

Search  time 
Time  Pet-  Element 

Independent  Variables 

Half  number  of  stimuli 


Page 

177  -  178 

Behaviors 

Reaction 

time 

Quantitativeness 

Scaled  Graphs 

Functions 

Supporting  Data 

n 

No  Validation 

Validation  with  Questionable  Results 

□ 

Validated 

Comments 

Critique  of  Teichner  and  Krebs,  1976,  #51 


K-202 


Reference 

Paskin,  H.M.  A  discrete  stochastic  optimal  control  model  of  th 
Human  Operator.  Atlanta,  GA:  American  Society  of  Mechanical 
Engineers,  11th  Joint  Automatic  Control  Conference  with  the 
American  Automatic  Control  Council,  1970,  Session  Paper  24-B, 
640  -  641. 

Appropriate 

No 

Dependent  Variables 


Independent  Variables 


Page 


Behaviors 


Quantitativeness 


Supporting  Da*~\ 

1  1  No  Validation 

1  1  Validation  with  Questionable  Results 
|  |  Validated 


Comments 


Reference 


Paskin,  H.M.  A  discrete  stochastic  optima'  control  model  of  the 
Human  Operator.  IEEE  Proceedings  of  the  National  Aerospace  Electronics 
Conference  (NAECON  '70  Record),  1970,  207  r  276. 


Appropriate nes 


Dependent  Variables 

Normalized  tracking  error 


Independent  Variables 

Input  bandwidth 
Conpensatory/ Pursuit  tracking 


Behavior? 


Movement  analysis 


Quantitativeness 


Functions 


Supporting  Data 


j  |  No  Va 1 i da t i o n 

|  |  Validation  with  Questionable  Results 
[i">3  Validated 


Comments 


Tracking  -  specific  application  of  the  optimal  control  model 


K-?04 


Reference 


■easuring  hrmsn  reliability?**  *‘aUtBan’  M-R-  A  faoily  of  models  for 


Appropriate 


Moderate 


Dependent  Variables  — - 

p““fn  reliabiUty  and  availability 

Man-Machine  system  effectiveness 
IndependentVariables  "  '  - - — - — 

Stress 

Proficiency 

Aspiration 

Fatigue 

Speed 

Precision 

Shifts 

Motion  Sickness 


112  -  H4 


Behaviors 


Reliability  Assessment 


Quantitativeness 

Nominal 


Supporting  Data 


jXX|  No  Validation 

□  Validation  ,1th  quaationabi.  Reaulta 

□  Validated 


K-205 


Reference 


Bradford,  W.H.,  A  mathematical  model  for  ditermining  the  probability 
of  visual  acquisition  of  ground  targets  by  observers  in  low-level 
high-speed  aircraft.  Alberqurque,  NM  Sandia  Laboratory  Technical 
Report  SC-TM-66-S4,  1966. 


Appropriate 

Medium 


Dependent  Variables 

CDF  of  acquisition  range 
Visual  air-to-ground 


Independent  Variables 

Slant  range  to  target 

Target  characteristics  (size,  orientation,  luminence,  contrast) 

Atmospheric  visibility 

Aircraft  characteristics 

Aircraft  Altitude 

Peripheral  vision 

Offset  of  aircraft  track  from  target  position 
Observer  scan  patterns 
Terrain  Masking 


Page 

22,  30 


Behaviors 

Detection,  Discrimination 

Quant i tat A venes s 

Functions 

Supporting  Data 

P  No  Validation 

□  Validation  with  Questionable  Results 

□  Val  i dated 


Comments 


Reference 


Franklin,  M.E.,  and  Wiiitenburg,  J.A.  Development  of  an  air-to-ground 
detection/identification  ndel.  U.S.  Aray  Human  Engineering  Laboratory 
Technical  Report  HSR- RR-65/4-D**  196S.  Contract  No.  DA-31-124-ARO-D-287. 


Appropriate 

Low 

Dependent  Variables 

Traget  detection/identification  air-to-ground 


Independent  Variables 

Target  si 2e 
Target  shape 
Target/ ground  contrast 
Clutter 
Terrain  type 
Aircraft  altitude 
Aircraft  speed 
Range 


Page 

62 


Behaviors 

Dection 

Discrimination 

Quantitativeness 

Functions 


Supporting  Data 

Q  No  Validation 

I  |  Validation  with  Questionable  Results 
□  Validated 

Comments 


Reference 


Goldstein,  I.L. »  and  Durtman,  P.W.,  Speed  and  load  stress  as 
determinents  of  performance  in  a  time-sharing  task.  Hunan  Factoi 
1978,  20  (S),  603  -  609. 

Appropriate 

Potential 

Dependent  Variables 

Performance  on  one  (or  several)  choice  RT  tasks 

Independent  Variables 

Speed  of  task  stress 

Number  of  simultaneous  tasks  (timesharing) 


Quantitativeness 

Scaled  Graphs 

Supporting  Data 

No  Validation 

Validation  with  Questionable  Results 
Validated 

Comments 


n 

□ 

□ 


Reference 


Rigney,  J.W.  and  Towns.,  D.M.  TASK  TTAQJr  A  method  for  computer- 
assisted  performance  training.  Human  Factors ,  1970,  1^  (3),  285  -  2%. 

Appropriate 

No 

Dependent  Variables 


Independent  Variables 


Supporting  Data 

□  No  Validation 

□  Validation  with  Questionable  Results 
|  |  Validated 

Comments 

This  article  addresses  task-analytic  techniques  rather  than  individual 
behavior  modeling. 


K-209 


Reference 


60 


s 

$ 

k> 

i 

m, 

V. 

■y 

•> 

K 


Briggs,  G.E.,  and  Johnston,  W.A.  Influence  of  a  change  in  system 
criteria  or  team  performance.  Journal  of  Applied  Psychology,  SO  (6), 
1966,  467  -  472. 


Appropriate 

Low 


Dependent  Variables 

Team  performance  or  a  simulated  radar  controlling  task 


V 


Independent  Variables 

Type  of  training  (performance  emphasis  on  speed  or  coordination) 


i. 


♦*, 

r 

r; 

Page 

496  -  471 

n 

Behaviors 

Group  compatabi litv 

Group  communication 

^ _ 

Quantitativeness 

Scaled  Graphs 

Supporting 

Data 

]  |  No  Validation 

r>:xj  Validation  with  Questionable  Results 

S' 

[  j  Validated 

i  . 

Comments 

This  represents  a  rather  obscure  independent  variable  for  this  effort. 

Also,  it  "ould  be  difficult  to  generalize. 

K-210 


trV 


Reference 


Johnston,  W.A.,  and  Briggs,  G.E.  Team  Performance  es  a  function  of 


team  arrangement  and  workload. 
1968,  89-94. 


Journal  of  Applied  Psychology,  52  (2] 


Appropriate 

High 

Dependent  Variables 

Amount  and  type  of  communication  among  'team  menbers 
Command  and  control  performance 


Independent  Variables 
Workload 

Compensatory  vs.  non-compensatory  team  arrangement 


Page 

92 

Behaviors 

Movement  Analysis 

Movement  prediction  Rate  Control 

Quantitativeness 

Scaled  Graphs 

Supporting  Data 

j  |  No  Validation 

□  Validation  with  Questionable  Results 
Validated 


Comments 


RefeTer.ce 


62 


Wortraan,  D.B.,  Hixson,  A.F.,  III,  and  Jorgensen,  C.C.,  A  SAINT  Model 
of  the  AN/TSQ-73  Guided  Missle  Air  Defense  System. 


/ 


Appropriate 

Low  (specific  behavioral  components  are  not  individually  modelled) 


Dependent  Variables 


Independent  Variables 


| - 

Page 


Behaviors 


Quantitativeness 


Supporting  Data 

]  ]  No  Validation 

I  J  Validation  with  Questionable  Results 
|  |  Validated 

Comments 


K-212 


Reference 


63 


Frederickson,  r..W.,  Folletie,  J.F.,  and  Baldwin,  R.  Aircraft  detection, 
range  estimation,  and  auditory  tracking  tests  in  a  desert  environment. 
Fort  Bliss,  TX:  Human  Resources  Research  Office,  Technical  Report  67-3, 
('  March  1967,  DA-44-188-ARO-2.  AD  650403 


Appropriate 

Yes 

Dependent  Variables 

Probability  of  detecting  B-52  aircraft  or  F-4C  or  A-6 


Independent  Variables 

Range  (  0  to  20  KM  ) 

Modality  (vision,  audition) 

Visual  aiding  (unaided,  6  X  30  binoculars) 

"  "  (6  X  30,  7  X  50  binoculars) 

Length  of  early  warning  (1,  5  minutes) 

Degree  of  terrain  masking 

Offset  from  flight  path  (200,  1400,  2600,  3300M) 


Page 

10,  15 

Behaviors 

Detection 

Quantitativeness 

Tables 

Scaled  Graphs 
Supporting  Data 

j  j  No  Validation 

□  Validation  with  Questionable  Results 
XX|  Validated 

Comments 


K-213 


Reference 


63 


Frederickson  et.  al.,  1967 


Appropriate 

Yes 


Dependent  Variables 

Range  estimates  of  fighter  and  bomber  flights 


Independent  Variables 

Flight  line  distance  (100  0,  15  00  ,  20  00  ,  2500  ,  30  00  ,  3500  ,  400  0  meters') 
Observer  offset  from  flight  path  (200,  1400,  2600,  3300  meters) 


Page 


18,  19 


Behaviors 

spatial  orientation 


Quantitativeness 

Tables 


Supporting  Data 

□ 

No  Validation 

□ 

Validation  with  Questionable  Results 

Validated 

Comments 

K-214 


Reference 


53 


Fredericks on,  et.  al.,  1967 


Appropriate 

Yes 


dependent  /ariables 

etection  range  for  A/C  structural  components 


Independent  Variables 

Observer  offset  (200,  1400  meters) 

Type  aircraft  (F-4C,  A-6,  B-52,  B-S8) 
Visual  aiding  (unaided,  6  X  30  binoculars 
Structure 


Page 

22,  23 


Behaviors  Detection 

Discrimination 

Quantitativeness 

Tables 

* 

Supporting  Data 

□ 

No  Validation 

□ 

Validation  with  Questionable  Results 

03 

Validated 

Comments 

K-215 


v 


Reference 


63 


Frederickson  ,  et.al.,  1967 


Appropriate 

Yes 


Dependent  Variables 

Time  delay  between  detection  and  identification  of  first  structural  coT.por.ant. 


Independent  Variables 

Observer  offset  (20d,  1400  meters) 

J  1  Visual  aiding  (unaided,  6  X  30  binoculars) 

Type  aircraft  (F-4C,  A-6,  B-52,  B-58) 


Page 

t 


25 


Behaviors  Detection 

Discriminat  lor, 
i 

(juanti  t  at  i  venes  s 

Table 

Supporting  Data 


n  No  Validation 

□  Validation  with  Questionable  Results 
Validated 


Commerts 


K-216 


Kefertnce 


Frederickson,  et.  al.,  1967 


P 


Appropriate 


Yes 


Dependent  Variables  — — 

Order  m  which  A/C  structures  were  detected 


Observer  offset  (200,  1400  meters) 

Type  aircraft  (F-4C,  A-6,  B-S2,  B-58) 

sSi«L-e  8  (Unaided>  6  *  30  binoculars) 


Page 


24 


Discrimination 


Supporting  Data 


Comments 


□ 

No  Validation 

□ 

Validation  v~th 

m 

Validated 

K-2I7 


Reference 

Frederickson,  et.  al.,  1967 

% 

% 


■*  ' 


Appropriate 

Yes 

Dependent  Variables 

Auditory  tracking  error 

Independent  Variables 

Slant  range  to  A/C 

Page 

29,  30 


^.■•shavior'  Auditory  detection 


Movement  analysis  j 

i 

Quantitativeness 

Tab  le 

Scaled  Graphs 

1 

! 

I 

Supporting  Data 

1  |  No  Validation 

[  |  Validation  with  Questionable  Results 

{xxj  Validated 


Comments 


K-213 


Reference 


Wokoun,  W.  Detection  of  random  low-altitude  jet  aircraft  by  ground  j 

observers.  Aberdeen  Proving  Ground,  MD:  Human  Engineering  Laboratory, 
Technical  mot  randua  7-60,  June  1960,  DA  Project  S416-04-012.  AD  238  .141.  1 


Appropriate 

Yes 

Dependent  Variables 

Probability  of  detecting  incoming  A/C 


i 


Independent  Variables 

Search  sector  size  (1-360°,  2-180°,  4-90*,  8-45*) 
Range  (  0  to  12,000  yds.) 

Aircraft  altitude  (500,  1500  ft.) 


Page 

23-35 

Behaviors 

Detection 

Quantitativeness 

Scaled  Graphs 

Supporting  Data 


□  Mo  Validation 

1  |  Validation  with  Questionable  Results 
£3  Validated 


Comments 


Reference 
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iv  Vt 


Wokoun  (1960) 


Appropriate 


Yes 


Dependent  Variables 

Probability  of  identifying  incoming  A/C 


Independent  Variables 

Search  sector  size  (1  -  360®,  2  -  180°,  4  -  90®,  8  -  45®) 
Range  (  0  to  12,000  yds.  ) 

Aircraft  altitude  (500,  1S00  ft.) 


m' 
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Mm H 

Behaviors 

§; 

Discrimination 

|:> 

Quantitativeness 

i* 

Scaled  Graphs 

i  ; 

Supporting  Data 

jj|* ; 

□ 

No  Validation 

□ 

Validation  with  Questionable  Results 

h  J . 

HI 

Validated 

Comments 


K-220 


Swiss'  \ 


Reference 


Wokoun  (1960) 


Appropriate 

Yes 

Dependent  Variables 

Range  of  incoming  A/C  when  detected 


Independent  Variables 

Search  sector  size  (1  -  360®,  2  -  180®,  4  -  90®,  8  - 
Time  (days  of  second  week) 


Page 


50 


Behaviors 

Detection 

Quantitativeness 

Table 

Supporting  Data 

Q  No  Validation 

□  Validation  with  Questionable  Results 
£3  Validated 

Comments 


Reference 


Wokoun  (1960) 


Appropriate 

Yes 

Dependent  Variables 

Range  of  * ucoming  A/C  when  detected 


Independent  Variable* 

Search  sector  size  (1  -  3608,  2  -  180°,  4  -  90°,  8  -  45°) 
Intertrial  interval  (0  -  15,  16  -  30,  31  -  45.  46+  minutes) 


Page 

51 

Behaviors 

Detection 

Quantitativeness 

Table 

Supporting  Data 


□  No  Validation 

£j  Validation  with  Questionable  Results 
53  Validated 


Comments 


Independent  Variables 

Search  sector  size  (1  -  360°,  2  -  180*,  4  -  90*,  8  -  45*) 

Course  of  incoming  A/C  (1  thru  6)  * 


Page 

51 

Behaviors 

Detection 

Quantitativeness 

Table 

_ I _ 

Supporting  Data 

|  |  No  Validation 

|  |  Validation  with  Questionable  Results 
£3  Validated 

Comments 


K-223 


04 


Reference 

Wokoun  (1960) 


Appropriate 

Yes 


■w  Dependent  Variables 

■>. 

|  Range  of  incoming  A/C  when  identified 

V 

s." 


Independent  Variables 

Search  sector  size  (1  -  360°,  2  -  180°,  4  -  90°,  8  -  45°) 
Course  of  incoming  A/C  (1  thru  6) 


Page 


52 


Behaviors 


Discrimination 


Quantitativeness 


» 


t  . 

f  * 


Supporting  Data 

|  1  No  Validation 

|  1  Validation  with  Questionable  Results 

[7y1  Validated 


Comments 


Reference 


64 


Wokoun  (I960) 


Appropriate 


Yes 


Dependent  Variables 

Range  of  incoming  A/C  when  detected 


j|  Independent  Variables 

Cross-over  range  (445  to  1335  yds.) 
Course  of  incoming  A/C  (1  thru  6) 

>  Site  of  observer 

1 


i 


Page 


53 


1 

Behaviors 

Detection 

Quantitativenes3 

Table 

Supporting  Data 

n 

No  Validation 

□ 

Validation  with  Questionable  Results 

*» 

%  ' 

M 

WV 

El 

Validated 

V 

Comments 

I 


> 


K-225 


( 


Reference 


64 


Wokoun  (1960) 


Appropriate 

Yes 

Dependent  Variables 

Range  of  incoming  A/C  when  identified 

Independent  Variables 

Cross-Over  range  (445  -  1335  yards) 
Course  of  incoming  A/C  (1  thru  6) 

Site  of  observer 


Page 

S3 

Behaviors 

Detection 

Quantitativeness 

Table 

Supporting  Data 

]  |  No  Validation 

|  |  Validation  with  Questionable  Results 

f\xj  Validated 

Comments 


K-225 


Reference 


Wokoun  (19601 

r 

Appropriate 

Yes 

Dependent  Variables 

Accuracy  of  A/C  identification 


Independent  Variables 

Type  of  A/C  (F-86,  F-100,  T-33) 
Altitude  (500,  1500  ft.) 


( 


Pa«e  54 

Behaviors 

Discrimination 

Quahtitativeness 

Table 

Supporting  Data 

n 

No  Validation 

□ 

Validation  with  Questionable  Results 

0 

Validated 

Comments 


* 


Reference 

Mallory,  W.J.,  and  Ellrctt,  T.K.  Measuring  troubleshooting  skills 
using  hardware-free  simulative.  Lowry  AFB,  Co.  Technical  Report 
AFHRL-TR- 78-47,  December  1978,  Contract  No.  F33615-77-C-0040.  ADA0640S4 


Independent  Variables 


Behaviors 


Quantitativeness 

Supporting  Data 

No  Validation 

Validation  with  Questionable  Results 
Validated 

Comments 

Discussion  of  a  personnel  selection  test  using  simulation. 


n 

□ 

□ 


K-2ZR 


Reference 


66 


Kubala,  A.L.  Problems  in  measuring  team  effectiveness.  ARI  Professional 
Paper  2  -  78.  DAHC  ir-75-C-0025,  January  1978.  ADA049560. 


Appropriate 

Low 

Dependent  Variables 


Independent  Variables 


Page 

Behaviors 

Quantitativeness 

Supporting  Data 

1  1  No  Validation 

□  Validation  with  Questionable  Results 
|  |  Validated 

Comments 

Concerned  with  measuring  team  effectiveness 


K— 22  9 


Inference 


67 


Goldstein,  I.G.,  and  Ringel,  S.  Survey  of  human  factors  problems  in 
missle  and  conununicati  on  systems..  Army  Project  Research  News,  APRO- 
RM-  60-17,  October  1960.  Project  No.  SL95-60-001.  ABD95127. 


Appropriate 

Low 

Dependent  Variables 

Performance  on  various  army  systems 


Independent  Variables 

Fatugue  -  stress  -  monotony 
Team  integration 
Environmental  conditions 
Relationships  with  support  services 
Administrative  considerations 


Page 

13  -  17 

« 

Behaviors 

No  specific  behaviors 

- - - _________ - p_ - - 

Quantitativeness  | 

Nominal 

Supporting  Data 

No  Validation 

□  Validation  with  Questionable  Results 

□  Validated  j 

- 

Comments 

General  survey,  no  objective  data  collected.  Not  likely  to  provide  information 
useful  for  quantitative  modeling. 


K-230 


Reference 


Collins,  J.J.  A  study  of  potential  contributions  of  small  gioup  behavic 
to  team  training  technology  development.  Arlington,  VA.  ONR  (code  452 
Technical  Report,  Contract  No.  N0014-  76-C-1076.,  1?77.  ADA04  3911 


Appropriate 

NO 


Dependent  Variables 


Independent  Variables 


Page 


Behaviors 


Quantitativeness 

Supporting  Data 

□  No  Validation 

LJ  Validation  with  Questionable  Results 

□  Validated 

Comments 

Good  discussion  of  team  performance  and  training.  No  specific  models  o 
data  presented. 


Reference 


9£0m 

-r. 


*.*:  4-1 
li 


Biede  iam,  L.R. ,  Gomer,  F.F..,  Levine,  S.H.  Dynamic  target  acquisition: 
Empirical  nr  dels  of  operator  performance.  Belling  AFB,  D.C.  AFOSrt 
Technical  Report  TR-80-1177,  August  1980,  Contract  No.  F4961.0-77-CC-Q1C0. 
ADA092263. 

Appropriate 

Potentially 

Dependant  Variables 

Response  time  and  probability  of  target  dection  and  recognition  (air-to-g 


“W-a 

m ? 


Independent  Variables 


Target  type 

Target  signture  (including  FLIR  and  TV  signature) 
Background  scene  complexity 
Closure  rate 
Slant  range 


: 

j .  3 


f  i. 

«  :•# 
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Pago 

78  -  82 

Behaviors  Detectio„ 

Discrimination 

Quanti tat ivenes s 

Functions 

Supporting  Data 


FI  No  Validation 

□  Validation  with  Questionable  Results 
Validated 


Comments 


May  be  most  useful  for  incorporating  the  effect  of  using  IR  recognition 
the  model.  Note  that  it  is  air-to-ground,  however. 


K-23? 


.  9 


Reference 


7 

Muray,  N.,  The  use  of  information  transmission  as  a  nonparametric 
correlation  in  the  analysis  of  complex  behavior:  a  preliminary  report. 
Office  of  Naval  Research  Technical  Report,  May  1380.  Contract  No.  N004-77-C 
ADA087832. 


Appropriate 

Low 


Dependent  Variables 


Independent  Variables 


Rage 

Behaviors 

Quantitativeness 

Supporting  Data 

□  No  Validation 

□  Validation  with  Questionable  Results 

□  Validated 

Coanents 

Provides  an  interesting  tool  for  determining  interrelationships  among 
system,  task,  and  human  performance  variable,  not  using  linear  correlation 
techniques.  However,  no  models  of  human  performance  are  presented,  peT  se 


K-Z33 


Reference 


Leahy,  W.R.,  Lautman,  M.R.,  Bearde,  J.L.,  and  Siegel,  A. I.,  A  digital 
simulation  model  of  message  handling  in  the  Tactical  Operations  System: 

III  further  extensions  of  the  model  for  increased  interaction.  USARI 
Technical  Report,  TR-77-A25,  October  1977,  Contract  No.  DAHC-19-72-C-0C03. 


Appropriate 


dependent  Variables 


Independent  Variables 


Behaviors 


Quantitativeness 


Supporting  Data 


1  |  No  Validation 

□  Validation  with  Questionable  Results 

□  Validated 


Coaments 


General  discussion  and  flowcharts  of  MANMODE  I..  No  specific  human  per  formal 
models  discussed.  Rather,  the  structure  of  MANMODEL  which  incorporates  hui 
performance  simulation  is  discussed. 


K-234 


Reference 


Lichtenstein,  S,  and  Fiscloff,  B.  How  well  do  probability  experts  assess 
probabilities?  Arlington,  VA:  ONR  Technical  Report,  PTR-10Q2-80-8, 
August  1980,  Contract  No.  N00014-80-C-0156  j  ADA08P619. 


Appropriate 

Medium 

Dependent  Variables 

Percentage  of  correct  responses 


Independent  Variables  s 

I 

Subjective  estimate  of  percentage  of  correct  responses  (confidence) 
Training  level  regarding  amount  of  confidence  in  decision  is  warrented 
*  Question  diffldulty 

?  I 


Page 


8 


Behaviors 


Practical  Judgement 
Meaningful  memory  ability 


Quantitativeness  j 

Scaled  Graphs 


Supporting  Data 

|  |  No  Validation 

I  |  Validation  with  Questionable  Results 
#CX!  Validated 


Comments 

May  be  useful  with  respect  to  training  people  on  ho w  confident  they  should 
be  for  their  visual  IFFN  identifications.  , 


/o 

Reference 


Kou,  R.S.,  Glass,  B.C.,  and  Viknanis,  M.M.  Reduced-order  observer 
model  for  AAA  tracker  response.  Wright  Patterson  AFB,  OH.  Technical 
Report  AMRL  TR-79-79.  August  1979.  Contract  No.  F33615-79-C-0500. 
ADA080932 


Appropriate 

High 

Dependent  Variables 

Tracking  Error  for  AAA  (azimuth  ard  elevation) 


Independent  Variables 

Approaching  target  angle  rate 
Approaching  target  angle  acceleration 
Observer  and  controller  gains 


Page 

26  -  30 

Behaviors 

Tracking 

Quantitativeness 

Functions 

Supporting  Data 


[~~1  No  Validation 

□  Validation  with  Questionable  Results 
xjxx]  Validated 


Comments 

Compares  model  to  OCM  in  terms  of  predictiveness,  computer  run  time,  and 
complexity.  Looks  very  good. 


K-236 


S  S 


•  Reference 


74 


r 


Farris,  R.N.  A  model  of  human  decision  making:  preliminary  research. 
Washington  Navy  Yard,  D.C.  :  NPRDC,  Technical  Report  WTR  73-5,  Augist 
1972.  AD748596 


Appropriate 

Medium 

Dependent  Variables 

Decision  making  efficiency  (Boysian) 


Independent  Variables 

Prior  odds 
Size  of  likelihood 
Amount  of  Evidence 
Data  conflict 
Response  mode 
Payoffs 

Data  sequence  characteristics 

Complexity  of  Decisions 

Sample  size 

Amount  of  experience 

Type  of  subjective  estimates 


Data  Fidelity 
Time  stress 

Non-independence  in  data 
Prior  uncertainty 


Page 

26 


B®haviorspracticai  judgement 
Logical  Evaluation 

_ General  reasoning _ 

Quantitativeness 

Nominal 

Supporting  Data 

No  Validation 

n  Validation  with  Questionable  Results 
[I  Validated 


Comments 


K-237 


7b 


Reference 

Finiley,  D.L.„  and  Muckier,  F.A.  Human  factors  research  and  the  development 
of  a  manual  systems  application  science:  The  systems  sampling  problem 
and  solution.  Naval  Analysis  Programs  (cede  431),  ONR,  Technical  Report, 
July  1976,  Contract  No.  N00014-74-C-0324.  ADA029417 

Appropriate 

Low 

Dependent  Variables 


Independent  Variables 


Pats 

Behaviors 

Quantitativeness 

Supporting  Data 

Q  No  Validation 

|  |  Validation  with  Questionable  Results 
Q  Validated 

Cor • ents 

General  discussion  of  taxonomies. 


K-238 


I 


;? 
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Reference 


76 


Baker,  J.D.  Quantitative  modeling  of  human  performance  in  information 
systems.  Army  Oehavior  and  Systems  Research  Laboratory.  Technical 
Research  Note  232,  Proiect  No.  20062106A723,  June  1972.  Ft.  Belvoir,  VA. 
AD746096.  Reprinted  f:x>m  Ergonomics  1970  _13  (6),  645  -  654. 


Appropriate 

Low 


Dependent  Variables 


independent  Variables 


Page 


Behaviors 


Quantitativeness 


P 


Supporting  Data 


J~~i  No  Validation 

n  Validation  with  Questionable  Results 
□  Validated 


h 

a  " 


n 


Consents 


General  discussion  of  a  modeling  approach,  no  specific  performance  models 
presented. 


K-239 


...  A- 


/ 

/ 

/  / 

Reference 

Wylie,  C.D.,  Dicks,  R.A. ,  and  Mackie,  R.R.  Toward  a  methodology  for 
man-machine  function  allocation  in  the  automation  of  surveillance 
systems  Volume  1:  summary.  Arlington,  VA:  Office  of  Nazal  Research, 
Technical  Report  1722  -  F,  Volume  L,  Jjly  1S7S,  Contract  No.  N00014-71-C-0301 . 
AD-A017  103. 


Appropriate 

Yes 


Dependent  Variables 

Variability  in  performance 


Independent  Variables 

Innate  abilities 
Training 

Operational  experience 
Motivation 


Page 


Behaviors 


Quanti tat i venes s 
Nominal* 

Supporting  Data 

n  No  Validation 

f~~]  'vtlidation  with  Questionable  Results 
□  Validated 

Comments 

Descrives  model  of  human  information  processing  in  surveillance  systems 
(p.  37  -  52) 

‘Taxonomy  on  pages  8-10 


K-2  40 


I 


t  V 


Reference 

Williams,  P.J.  Kurtz,  G.L.,  ai.d  Grubash,  J.W.  An  evaluation  of  operator 
performance  on  the  Patriot  Display  and  Central  Console.  Human 
Engineering  Lab,  /tberdeen,  MD,  LIEL-TM-1S--77,  May  1977.  ADB020664L 


Supporting  Data 


□  No  Validation 

□  Validation  with  Questionable  Results 

□  Validated 

Comments 

Specific  test  of  design  changes  to  Patriot  Console.  May  be  useful  during 
validation  because  of  data  presented  on  operation. 


K— 241 


Reference 


78 


Teper,  G.L.  An  assessment  of  the  "paper  pilot"  -  An  analytical 
approach  to  the  specification  and  evaluatior  of  flying  qualities. 
Wright-Patterson  AFB,  OH:  Air  rorce  Flight  Dynamics  laboratory, 
AFFDL-TR-71,  174,  June  1972,  Contract  No.  5-71-0-1071 


Appropriate 

No 


Dependent  Variables 

Pilot  rating  of  flying  qualities 


Independent  Variables 

j 

System  characteristics 
Environmental  variables,  eg.  gusts 


Page 


Behaviors 


Quantitativenes3 

Scaled  Graphs 
Nominal 

(6  - 

■8) 

Supporting  Data 

n 

No  Validation 

□ 

Validation  with  Questionable  Results 

j 

Validated 

Comments 

K-242 


Reference 


79 


Oatman,  L.C.  Target  detiction  using  black-and-white  television.  Study  1: 
The  effects  of  resolution  degradation  on  target  detection.  Aberdeen 
Proving  Ground,  MD:  Army  Human  Engineering  Laboratory,  Technical  Memorandum 
9-65,  July  1965,  Contract  No.  AD  625.15 


Appropriate 

No  (?) 


Dependent  Variables 

Probability  of  detecting  an  M-48  tank 
(correct  detection  scores,  response  time) 


Independent  Variables 

TV  resolution  (800,  600,  400,  300  lines) 


/' 

\  . . . . ,  . 

Page 

5,  6,  9  -  12. 

Behaviors 

Detection 


Quanti tativenos s 

Scales  Graphs 
Tables 

Supporting  Data 

n  No  Validation 

□  Validation  with  Questionable  Results 
0  Validated 

Comments 


Ground-to-ground  oriented 


K— 243 


Reference 


80 


Muralidharan,  R.,  Baron,  S.,  and  Feehrer,  C.  A  decision,  monitoring,  and 
control  model  of  the  human  operator  applied  to  an  RPV  control  problem. 

Final  Scientific  Report.  Bolling  AFB,  D.C.  Air  Force  Office  of  Scientific 
Research,  AFOSR-TR- 79-v675,  March  1969,  Contract  Mo.  F44620- 76-COO 29. 

NTIS  AD  AO  69880. 


Appropriate 

? 


Dependent  Variables 

Temporal  monitoring  behavior 


Independent  Variables 

Strategy 

Ground  speed  (ETA) 

Lateral  deviation  error  (LATDEV) 

Disturbances 

(see  input  parameters  p.  52  for  complete  list) 


Page 


39 


Behaviors 


Quantitativeness  ij 

Nominal  (pgs .  20,  50)  Functions  (pgs.  39,  41,  44,  47,  48) 

_ Scaled  Graphs  (pgs.  61,  63,  65)  j _ _ 

Supporting  Data  i 

□  No  Validation 

□  Validation  w..n  Questionable  Results 
j  |  Validated 


Comments 

Decision  making  structure  of  DE'TDN  (decision-making,  monitoring  and  control 
model)  is  based  on  expected  net  gain  (ENG)  (a  criterion  for  national  choice 
among  alternatives). 


K-244 


Reference 


Muralidharan,  et.  al . .  1969 


r 


Appropriate 

? 


Dependent  Variables 

Monitoring  looks 


Independent  Variables 

Workload  (number  of  controled  RPV's) 


Page 

67,  69 

Behaviors  ... 

Vigilance 

Discrimination 

Quantitativeness 

Scaled  Graphs 

Supporting  Data 

□ 

No  Validation 

□ 

Validation  with  Questionable  Results 

m 

Validated  by  simulation 

Comments 


Reference 


Miller,  D.C.,  Feehrer,  C.E.,  Muralidharan,  R. ,  Pew,  R.W.,  and  Baron,  S. 
Development  of  human  performance  models  for  man-machine  system  sireulatios 
Bolling  AFB,  D.C.:  Air  Force  Office  of  Scientific  Research,  AFCSR-TR-79< 
October  1978,  F44620-76-C-0029.  AD  A069879. 


Appropriate 

Yes  (?) 

Dependent  Variables 

Patching  decision 

Patch  command  computation  and  generation 


Independent  Variables 
Disturbance 

Presence  or  absence  of  patch  control  (correct  deviation  in  flight  path  a 


Page 


See  Quantitativeness 


Behaviors 


Deci  sion-na.king 


Quanti tat i venei s 

Nominal  (pg.  41)  Functions  (pgs.  36-39,  52-60) 


Supporting  Data 

□  Mo  Validation 

I  |  Validation  with  Questionable  Results 
fHj  Validated  (data  not  given) 


Comments  ,  „ 

2nd  year  report  of  3  year  efiort 

"nodi fy  optimal  control  model  of  human  operator  by  incorporating  struct! 
notions  that  make  it  suitable  for  application  to  p-tob  lores  in  which  humi 
control  actions  are  infrequent  and  in  which  monitoring  and  decision-real 
are  the  operator's  min  activities"  (Pg .  32) 

Top- down 

SAINT  compatible  (Appendix  C  has  software  modifications) 


Reference 

Hoffman,  H.c.  Preliminary  re;  ults  of  trials  to  determine  the  maximum 
range  of  perception  of  fast  aircraft.  Aircraft  Institute,  German  Aviatiof 
and  Space  Research  Center,  R.R.E.  Translation  No.  171,  April  1967.  N68  2J 


Appropriate 


Yes 


. - - - - -  - - . — . .  . mi 

Dependent  Variables  \ 


Maximum  perception  range 


Independent  Variables 

Horizontal  standard  visibility 
Uhaided  vs.  10  X  50  binocular? 


P*!**  2-4  (unnumbered)  unaided;  5-7  aided 


Behaviors 

Detection 


Quantitativeness 

Scaled  Graphs 


Supporting  Data 

□ 

No  Validation 

□ 

Validation  with  Questionable  Results 

0 

Validated 

Co aments 


K-247 


Reference 


Siegel,  A.S.  and  Wolf,  J.J.  Man-machine  simulation  models.  New  York: 
Wiley  -  Interscience,  1969. 


Appropriate 


Dependent  Variables 

Group  performance 

Subtask  execution  time  (pg.  25) 
Subtask  success/failure  (pg.  25  -  26) 


----  one  or  two  individuals 


Independent  Variables 

Urgency  (pg.  22) 

Team  cohesiveness  (pg.  23) 
Goal  aspiration  (pg.  26) 
Stress 


one  or  two  individuals 


Individual  orientation  towards  group  goal  achievement 
Communications 

Environment  -  Group  performanct 

Crewmember  proficiency 
Crew  Morale 


Page 

See  above 

Behaviors 

Across  all 

behaviors 

Quantitativeness 

Functions 

Supporting  Data 

n 

No  Validation 

m 

Validation  with  Questionable  Results 

□ 

Validated 

Comments 

Describes  Siegel  Wolf  model ,  looks  to  be  of  great  value  for  including  sonx 
group  variables. 


Reference 

Warner,  H.D.,  and  Meimstra,  N.W.  Effects  of  noise  intensity 
target-detection  performance.  Human  Factor;,  1972,  1£,  181  - 


Appropriate 

Yes 


Dependent  Variables 

Detection  time 
Detection  error 


Independent  Variables 

Noise  level  (0,  80,  90,  100  dB  white  noise)  (headphones) 
Difficulty  (8,  16,  32  background  letters  in  display) 
Target  location  (central,  peripheral  regions  of  display) 


Pa8«  183  -  184 


Behaviors 


Detection 


Quanti tativenei s 
x  Tables 

Scaled  Graphs 


Supporting  Dati 


[31  No  Validation 

□  Validation  with  Questionable  Results 
[X>J  Validated 


Reference 


8 

Hammill,  H.B.  The  effect  of  magnification  and  profile  scaling  on  the 
visual  tracking  system.  Buffalo,  NY:  Cornell  Aeronautical  Laboratory, 
Pen/al  Memo  No.  3686,  May  1972 


Appropriate 

Yes  (?) 


Dependent  Variables 

Tracking  error  (pg.  3) 

Observer  reaction  time  (pg.  3) 


Independent  Variables 

Optical  magnification 
Aircraft/observer  range  vector 


Page 

Behaviors 

Tracking 

Movement  prediction 

Rate  control 

Quantitativeness 

Functions 

Supporting  Data 

S3 

No  Validation 

□ 

Validation  with  Questionable  Results 

□ 

Validated 

Comments 

Establishes  a  flight  profile  rescaling  factor 


K-2  50 


86 


Reference 

Sugaraan,  R.C.,  Hammill,  H.B.,  and  Deutsc.hman,  J  N.  a  modified  model  for 
visual  detection.  Paper  presented  at  the  Fifth  Naval  Training  Equipment 
Center  and  Industry  Conference,  February  1972. 


Appropriate 

Yes 


Dependent  Variables 

Probability  of  detection 


Independent  Variables 

Target  contrast 


Threshold  contrast 


Ratio 


Page 

2 

Behaviors 

Detection 


Quantitativeness 

Scaled  Graphs 


Supporting  Data 

EH 

No  Validation 

□ 

Validation  with  Questionable  Results 

□ 

Validated 

Comments 


Reference 


Sugarman,  et.  al.,  1972 


Appropriate 


Dependent  Variables 


Threshold  difference 


Independent  Variables 


Size  of  test  object 
Nasal  vs.  temporal  field 


Behaviors 

Detection 

Quantitativeness 

Scaled  Graphs 

Supporting  Data 


|  [  No  Validation 

□  Validation  with  Questionable  Results 


XX  Validated 


Comments 


K-252 


Reference 

Sugarman,  et.  al.,  1972 


Appropriate 

Yes 

Dependent  Variables 

Average  detection  probability  for  single  glimpse 


Independent  Variables 

Peripheral  angle  within  visual  field 
"  "  in  the  real  world 


Page 

3.  8 

Behaviors 

Quantitativeness 

Functions  (pgs.  3,  8) 

Supporting  Data 

PI  No  Validation 

I  |  Validation  with  Questionable  Results 
Ixxi  Validated 

Comments 


Reference 


86 


Sugarman,  et.  al.,  1972 

/ ' 

Appropriate 

? 

Dependent  Variables 

Peripheral  angle  distributions 


Independent  Variables 

Target  location 


Page 

10 


Behaviors 

Detection 

Quantitativeness 

Scaled  Grains 

Supporting  Data 

n 

No  Validation 

□ 

Validation  with  Questionable  Results 

£3 

Validated 

Costtents 


K-254 


Reference 


86 


Sugarnnn,  et.  al.,  1972 


r 


Appropriate 


Quanti tativenes  s 

Scaled  Graphs 

Supporting  Data 

|  |  No  Validation 

I  |  Validation  with  Questionable  Results 

» 

1  1  Validated 

Comments 


K— 255 


Page 

14 

_ * 

Behaviors 

Detection 

"  i 

Quantitativeness 

Functions 

Supporting  Data 

□  No  Validation 

□  Validation  with  Questionable  Results 
Validated 

Coannents 

I 

K-256 


i 


Reference 


87 


Sugarman,  R.C.,  Hammill.  H.B.,  and  Deutschman,  J.N.  Simplifying  dynamic 
visual  detection  simulations.  Paper  presented  at  the  Fifth  Naval  Training 
Equipment  Center  and  Industry  Conference,  February  1972. 


Appropriate 

Yes 


Dependent  Variables 

Probability  of  detection 


Independent  Variables 

Target  subtense  angle  (taget  size) 

Contrast 

Structure 


Page 

10 

Behaviors 

Detection 

Quantitativeness 

Scaled  Graphs 

Supporting  Data 

1  |  No  Validation 

□  Validation  with  Questionable  Results 
0  Validated 

Comments 


K-257 


Reference 


Sugarman,  et.al.,  1972 

'  i 

Appropriate 

Yes 

Dependent  Variables 

Detection  false  alarm  rate 

Independent  Variables 

Days  performed 


Page 

8 

Behaviors 

Detection 

Quantitativeness 

Table 

Supporting  Data 

1  |  No  Validation 

□  Validation  with  Questionable  Results 
Ex!  Validated 

Comments 


K-258 


Reference 

Sugarman,  et.  al.,  1972 


Appropriate 

Yes 

Dependent  Variables 

Detection  hit  rate 


Independent  Variables 

Days  performed 


Pago 

8 

Behaviors 

Detection 

Quantitativeness 

Table 

Support  ini  Data 

□ 

No  Validation 

□ 

Validation  with  Questionable  Results 

S3 

Validated 

Comments 


Reference 

Hammill,  H.B.  Visual  detection  model  for  structured  targets.  Paper 
presented  at  the  Twelfth  Annual  Pittsburgh  Conference  of  Modeling  and 
Simulation,  April/May  1981. 

r 


Appropriate 

Yes 

Dependent  Variables 

Detection  probability 

Independent  Variables 

Threshold  contrast 

Target  contrast 

Page 

i.: 

Rehaviors 

Detect  ion 


Quant  i  tat  iver.es  s 

Functions 

Supporting  Data 

P  Ho  Validation 

□  Validation  with  Questionable  Results 
vii  Validated 


Independent  Variables 

|T|irget  subtense 
(Contrast 


Page 


8 


Behaviors 

Detection 

i 

Quanti tativenes s 

Scaled  Graphs 


Supporting  Data 

[~]  No  Validation 

□  Validation  with  Questionable  Results 
0  Validated  j 


Cooaents 


Reference 

Kinkadc,  R.S.,  Kidd,  J.S.,  and  Ranc,  M.P,  A  study  of  tactical  decision 
making  behavior.  Hanscom  Freed,  MA:  Decision  Sciences  Laboratory, 
ESD-TR-66-61,  November  1965,  Contract  No.  AF  19  (626)  -  4792. 


Appropriate 

Yes 


Dependent  Variables 

Tactical  decision  making 


Independent  Variables 

Environment 
Weapon  system 
Information  system 
Perceived  environment 
Desired  environment 


Action 

Action 

selection 

evaluation 

Page? 

a 

Behaviors 

Decision  making 

Quantitativeness 

Nominal 

* 

Supporting  Data 

E3 

No  Validation 

□ 

Validation  with  Questionable  Results 

□ 

Validated 

Comments 


Kinkade,  et.  al.,  1965 


Reference 

i  . 

Appropriate 

Dependent  Variables 

Percent  of  selection 

Independent  Variables 

Number  of  alternatives  (2,4,6) 


Page 

S3 

Behaviors 

Decision  making 

Quantitativeness 

Scaled  Graphs 

Supporting  Data 

1  |  No  Validation 

□  Validation  with  Questionable  Results 
gx]  Validated 

Coaaents 


K-263 


inference 

:>  Kinkade,  et.  al.,  1965 


Appropriate 

Dependent  Variables 

Error  in  estimation  probability  of  success 

Independent  Variables 

Number  of  alternatives  (2,4,6) 

Probability  (low,  medium,  high) 


Behaviors 

Probability  estimation 

Quanti tat ivenes s 

Scaled  graphs 

Supporting  Data 

n  No  Validation 

|  |  Validation  ••'ii.n  Questionable  Results 
fTx]  Validated 

Co  assents 


Reference 


Kinkade,  et.  al.,  196S 


r 


Appropriate 

Yes 


Dependent  Variables 

Percent  of  correct  choices 


Independent  Variables 

Probability  of  success  (high,  medium,  low) 
Number  of  alternatives  (2,4,6) 


Page 

46,  51 

Behaviors 

Decision  making 

Quantitativeness 

Scaled  Graphs 

Supporting  Data 

□ 

No  Validation 

□ 

Validation  with  Questionable  Results 

0 

Validated 

Co  assents 

K-265 


Reference 

Kinkade,  et.  al . ,  1965 


r 


Appropriate 

Yes 

Dependent  Variables 

Error  in  probability  estimation 


Independent  Variables 

True  probability  of  success  (lew,  medium,  high) 
Number  of  alternatives  (2,4,6) 


Page 

46 


Behaviors 

Probability  estimation 

Quantitativeness 

Scaled  Graphs 

Supporting  Data 

□ 

No  Validation 

□ 

Validation  with  Questionable  Results 

Validated 

Comments 


Reference 


Kinkade,  et.  al.,  1965 


Appropriate 

Yes 

Dependent  Variables 

Frequency  of  tactic  selection 


Independent  Variables 

Number  of  alternatives 


Behaviors 

Decision  making 

Quanti tativenes  s 

Scaled  Graphs 


Supporting  Data 


j  |  No  Validation 

□  Validation  with  Questionable  Results 
Validated 


Comments 


K— 267 


Reference 


Kinkade,  et.  al.,  1965 


Appropriate 

Yes 

Dependent  Variables 

Error  in  probability  estimation 

Independent  Variables 

Feedback  (Ps,  outcome) 
Instructions  (correct,  incorrect) 


Page 

39 

Behaviors 

Probab'lity  estimation 

Quantitativeness 
Table 

Supporting  Data 

f~~1  No  Validation 

LJ  Validation  with  Questionable  Results 
fix]  Validated 


i 


Comments 


K-268 


Reference 


89 


/ 


/ 


/ 


Kinkade,  et.  al.,  1965 


f 


Appropriate 

Yes 

Dependent  Variables 

Percent  of  correct  choices 


Independent  Variables 

Block  of  problem  (  1  to  4  ) 
Feedback  (true  Fs,  outcome) 
Instruction  (correct,  incorrect) 


Page 

36 

Behaviors 

Decision  making 

Quantitativeness 

Scaled  Gra;hs 

Supporting  Data 

n 

No  Validation 

□ 

Validation  with  Questionable  Results 

Validated 

Comments 

K— 269 

i 


Reference 


Kinkade,  et  al.,  1965 


Appropriate 

Yes 


Dependent  Variables 

Average  error 


Independent  Variables 

Correct  vs.  incorrect  choices 

Feedback  (true  Ps,  5  error,  10  error,  outcome) 


Page 

32 

Behaviors 

Decision  making 

Quantitativeness 

Table 

Supporting  Data 


□  No  Validation 

'alidatico  with  Questionable  Results 

[>H  Validated 

Comments 


K-270 


•Reference 


Kinkade,  et.  al.,  1965 


Appropriate 

Yes 

Dependent  Variables 

Percent  correct  choices 

Independent  Variables 

Magnitude  of  probability  of  success 
Feedback  (true  Ps,  5  error,  10  error,  outcome) 


Behaviors 

Decision  making 

Quant-  ' . eness 

..  ..  .il  ---d  Graphs 

S  ing  Data 

1  |  No  Validation 

□  Validation  with  Questionable  Results 


J(XJ  Validated 


Reference 


Kinkade,  et.  al.,  1965 


r 


Appropriate 

Yes 

Dependent  Variables 

Percent  of  correct  choices 


Independent  Variables 

Feedback  condition  (true,  5  error,  10  error,  outcome) 


Page 

29 

Behaviors 

Decision  making 

Quantitativeness 

Scaled  Graphs 

Supporting  Data 

n 

No  Validation 

□ 

Validation  with  Questionable  Results 

E3 

Validated 

Comment  s 


K-272 


Appropriate 

Yes 

.  Dependent  Variables 

i 

Estimate  time 

Independent  Variables 

Blocks  of  problems 


Page 

23 

3ehaviors 

Time  estimation 


Quantitativeness 

Scaled  Graphs 

Supporting  Data 

□  No  Validation 

□  Validation  with  Questionable  Results 
{>3  Validated 


Comments 


S:’\TT 

fs0k't 


Reference 


Kinkade,  et .  al.,  1965 


Appropriate 


ft; 

■A  £*&  ••■al'itjslv-  fh\  i 


Dependent  Variables 
Select  time 


- 1  ■&:*’ 


Independent  Variables 


Blocks  of  probl£_s 


•*pr9- 

•  i' 

..f  • 

j-  • 

.  ■  V  . 

c  ,» 


',V> 

uv'- 

..vV.-. 

•.**:  r--  ,JI 


Behaviors 


Decision  time 


•  © 


Quanti tativeness 

Scaled  Graphs 

Supporting  Data 


□  No  Validation 

□  Validation  with  Questionable  Results 
fxx]  Validated 


.  .>  .  .•  .• 


Comments 


K-274 


Reference 


Xinkade,  et.  »1.,  1965 


Appropriate 

Yes 

Dependent  Variables 

Error  in  estimating  probability  of  success 


Independent  Variables 

Type  feedback  (outcome  feedback  vs.  correct  .answer  feedback! j1 


Page 

21 


Bel 

haviors 

i  Probability  estimation  j 

Qui 

bititativeness 

Scaled  Graphs 

Supporting  Data 


□  »' *  Validation 

□  Validation  with  Questionable  Results 
py  Validated 

Comments 


K— 27  5 


Reference 

Kinkade,  rt.  al.,  1965 


Appropriate 

Yes 

Dependent  Variables 

Percent  correct  choices 

Independent  Variables 

Warning  vs.  no  warning 


Page 

22 

Behaviors 

Decision  making 

Quantitativeness 

Scaled  Graphs 

Supporting  Data 

□ 

No  Validation 

□ 

Validation  with  Questionable  Results 

m 

Validated 

Comments 


K-27G 


\ 


Reference 

Itinkade,  et.  *\1.»  1965 


Appropriate 

Yes 


Dependent  Variables 

Quality  of  tactical  decision  performance 
(percent  of  correct  choices) 


Independent  Variables 

Frequency  of  change  in  system  state  (1  vs.  3) 


Page 

21 


Behaviors 

Decision  making 

Quantitativeness 

Scaled  Graphs 

Supporting  Data 

□  No  Validation 

□  Validation  with  Questionable  Results 
]X%1  Validated 

Comments 


K-?77 


Reference 


(■  ‘ 

,  f . 


-  .<  . 
V'V 

t'sNfc  / 

: 


?  ,  J 


•  ■  t.  - 

••  •  ,<C.  v 
*>  •  .• 


C  # 

**"  S*  - 
f. 


Levis,  D.  and  Low,  W.F.  Retention  of  skill  on  the  SAM  complex  coordinate* 
Acaderrv  of  Science,  1956,  63,  S91  -  59;*. 


* 


Appropriate 


Dependent  Variables 

Nuui>er  of  matches  (red  lights  to  adjacent  green  lights) 


Independent  Variables 


Practice  session 

Distributed  vs.  massed  practice 


Page 

594 

jehaviors 

Discrimination 

Quantitativeness 

Scaled  Graphs 

Supporting  Data 

□  No  Validation 

□  Validation  with  Questionable  Results 


Validated 


Comments 


K-773 


Reference 


9< 


Lewis  and  Low,  !956 

✓ 


Appropriate 

Dependent  Variables 

Variance  of  matches 


Independent  Variables 

Practice  session 


Page 

595 

Behaviors 

Discrimination 

Quantitativeness 

Table 

Supporting  Data 

□ 

No  Validation 

□ 

Validation  with  Questionable  Results 

Validated 

Comments 


90 


Reference 

Lewis  and  Low,  19S6 


Appropriate 


Dependent  Variables 

Number  of  matches 


Independent  Variables 

Practice  session 
Proficiency  (high  vs.  low) 


Page 

596,  597 

Behaviors 

Discrimination 

Quantitativeness 

Scaled  Graphs 

Supporting  Data 


□ 

□ 

Ixx] 


No  Validation 

Validation  with  Questionable  Results 
Validated 


Comments 


K-2B0 


Reference 


Wainer,  H.  Estimating  coefficients  in  linear  models:  it  don't  make  no 
nevermind.  Psychological  BtllJtin,  1976,  83,  213  -  217. 

Appropriate 

No 

Dependent  Variable* 


Independent  Variables 


Page 

Behaviors 

Quantitativeness 

Supporting  Data 

]  |  No  Validation 

□  Validation  with  Questionable  Results 

□  Validated 

Comments 

Presents  Equal  Weights  Theorum:  coefficients  in  multiple  regression  models 
can  be  replaced  with  equal  weights  with  almost  no  loss  in  accuracy  ci  the 
original  data  sample. 


Reference 


92 


Akcrnan,  A.,  Ill,  and  Kinzly,  R.E. 
Human  Factors ,  1979,  21  (3),  277  - 


( 

Predicting  aircraijt  detectability. 


291. 


Appropriate 

Yes 

Dependent  Variables 

Contrast  threshold 

_ _ * _ L 

Independent  Variables 

* 

l1'  ' 

Daylight  only  - 

Target  size  (<^L) 

j 

Retinal  position  (& ) 

Pago 

27  5 

t 

Behaviors 

Detection  i 

!  . 

Quantitativeness 

Nominal 

Supporting  Data 


□  No  Validation 

□  Validation  with  Questionable  Results 

□  Validated 


Comments 

VIDEM  model  -  detectability  of  aircraft  against  sky  background. 

This  paper  reviews  two  components  of  VIDEM  -  Liminal  contrast  threshold 
and  frequency-of-seeing  curve. 


I 


Reference 

Akerman,  et.  al.,  1979 


r 


Appropriate 

Yes 

Dependent  Variables 

Single  glimpse  detection  probability 


Independent  Variables 

Apparent  contrast/threshold  contrast  (C/Ct) 


92 


lO 


Page 

280 

Behavior 

Detection 

Quantitativeness 

Scaled  Graphs 

Supporti-*  Data 

□  No  Validation 

□  Validation  with  Questionable  Results 

□  Validated 

Comments 

Koopman's  empirical  curve 


K-283 


/  / 

/ 

Reference 

Akerman,  et.  ai.,  1979 


Appropriate 

Yes 

Dependent  Variables 

Liminal  Brightness  Contrast  Threshold 
Mairani  1 1/Sloan  model 

Independent  Variables 

Target  size 
OC  Retinal  position 


92 


Page 

282 


Behaviors 

Detection 
Quant  i  t  at  .i  v  er.es  s 


Supporting  Data 

1  |  No  Validation 

(^~j  Validation  with  Questionable  Results 
|  |  Validated 

Comments 

©  is  the  angle  between  the  fovea 1  fixation  axis  and  the  observer- target  axis. 


K-284 


R-jference 


Akerman,  et.  al.,  197 


Appropriate 

Yes 

Dependent  Variables 

Probability  of  detection 


Independent  Variables 
Slant  range 


VIDEM  Model 


Behaviors 


Detection 


Quantitativeness 

Nominal 


Functions 


Supporting  Data 


Comments 


1  !  No  Validation 

□  Validation  with  Questionable  Results 


m  Validated 


VIDEM  uses  Hammi 11/Sloan  Ct 

Soft  shell  search  (p(©)  for  angles) 

Discrete  cumulation  over  1/3  second  gll;  ase  intervals 


K-Z85 


93 


Reference 

Cart*.  R.C..  and  Cahill,  M.  Regression  models  of  search  time  for 
color  coded  infnrration  displays.  Huma.-  Factors ,  1C79,  2_1_  (3),  293  -  302. 


,'npropriate 

Yes 


Dependent  Variables 

Search  time 


Independent  Variables 

Number  of  coding  colors 

Display  density  (number  of  background  stimuli) 


Page  295 


Behaviors 

Identification 

Quantitativeness 

Scaled  Graphs 

Supporting  Data 

T  ]  .'•o  Validation 

[_J  Validation  with  Questionable  Results 
[[H  Validated 

Comments 


'<-236 


fAT jrwj^&'x.vr  *1 

it 


ti'  f 


IA 


[A 


Reference 


Carter,  et.  al.,  1979 


Appropriate 

Yes 


Dependent  Variables 

Mean  search  time 


Independent  Variables 

Number  of  items  in  each  color  category 


Page 

297 


Behaviors 

Identification 

Quantitativeness 

Scaled  Graphs 

Supporting  Data 

J3J  No  Validation 

|  |  Validation  with  Questionable  Results 
□  Validated 

Comments 

Good  linear  fit 


K-2S7 


«* 


4  , 


} 

j 

Reference 

Burmeister,  E.  Uniqueness  of  rest  points  for  optim.il  control  models 
in  economics.  Automatics,  1978,  14,  157  -  160.  j 


Appropriate 

No 


Dependent  Variables 


I 


Independent  Variables 


v 

•  * 


I, 


gj 

Page 


Behaviors 


Quantitativeness 

i 

! 

►  - - - 

Supporting  Data 

n  No  Validation 

□  Validation  with  Questionable  Results 
I""!  Validated 

Comments 

Based  on  capita  production  functions  economics  model. 


K-288 


Reference 

Siegel,  A. I.,  Wolf,  J.J.  and  Leahy,  W.R.  A  digital  simulation  model 
of  message  handling  in  the  Tatical  Operations  System:  I.  The  model,  its 
sensitivity,  and  user's  manual.  Alexandria,  VA:  U.S.  Army  Research 
Institute  for  the  Behavioral  and  Social  Sciences,  Technical  Report 
TR-77-A23,  October  1977,  Contract  No.  DAHC  19-72-C-0003.  ADA047104 


Appropriate 

Yes 


Dependent  Variables 


Independent  Variables 


r- 


i 


Page 


Behaviors 


Quantitativeness 


Supporting  Data 


P%]  No  Validation 

I  |  Validation  with  Questionable  Results 
□  Validated 


Comments 


2,  20,  and  99  person  model  versions. 

Messages  are  to  computer-basdd  system  via  typewriter,  keyboard,  CPT 


*If  this  model  is  used  extensively,  see  Part  II  ADA046407  #90  for  added  improveme 
responsiveness,  effectiveness,  multiple  input  messages,  undetected  errors  and  st 
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Reference 

Siegel,  et.  al.,  1977 


Appropriate 

yes 

Dependent  Variables 

Pace  adjustment  factor 


Independent  Variables 

Aspiration  -  Performance  difference.  This  represents  an  operational! zatit 
of  goal  discrepancy. 

Stress  above  or  below  threshold.  The  stress/discrepancy  combinations  are 
broken  into  four  cases.  P.29  has  cases  1  §  3;  in  case  2,  pace  *  1;  in  ca.‘ 
pace  •  1,  stress  «  90%  stress. 


Page 

28-30 

Behaviors 

Aspiration 

Quantitativeness 

Nominal  Scaled  Graphs 

Supporting  Data 

□  No  Validation 

□  Validation  with  Questionable  Results 

□  Validated 

Comments 


Reference 


Siegel,  et.  al.,  1977 


Appropriate 


Dependent  Variables 


Pace  adjustment  factor 


Independent  Variables 

Hours  after  starting  work  -  up  to  10  (12)  hours 
Over  9  days  (fatigue) 


Page 

30  -  33 

Behaviors 

Quantitativeness 

Scaled  Graphs 
Functions 

Supporting  Data 

1  |  No  Validation 

n  Validation  with  Questionable  Results 
□  Validated 

Comments 

Based  on  one  study  of  air  traffic  controllers 


K-291 


•Reference 

Siegel,  et.  al.,  1977 


Appropriate 

Yes 

Dependent  Variables 

Pace  adjustment  factor 

Independent  Variables 

Stress  due  to  message  backlog 


Page 

34 

Behaviors 


Quantitativeness 

Unsealed  Graphs 

Supporting  Data 


Comments 


1  |  No  Validation 

□  Validation  with  Questionable  Results 

□  Validated 


Reference 


Siegel,  et.  al.,  1977 


Dependent  Variables 

Execution  time 


Independent  Variables 


Individual  differences  due  to  speed 
Stress  adjustment  factor 
Message  length 


Quantitativeness 

j  Functions 


Supporting  Data 


PI  No  Validation 

□  Validation  with  Questionable  Results 

□  Validated 


Comments 


K-293 


Reference 

Siegel,  et.  al.,  197? 


r" 
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95 


Appropriate 

Dependent  Variables 

Task  element  success  probability  change 

Independent  Variables 

Operation  precision 


Page 

40,  122  (function) 

Behaviors 

ii 

0. 

Quant i tativeness 

Scaled  Graphs 

Functions 

Supporting  Data 

|  |  No  Validation 


□  Validation  with  Questionable  Results 

□  Validated 


Comments 


K-294 


*  It  "  ./t  _»*  *  •*  .*.*»  jut i!j  A*-*  *  J 


Reference 


Siegel,  et.  al.,  1977 


Appropriate 

Yes 


Dependent  Variables 

Task  element  success  probability  change 


Page 

41,  122  (Functions) 

Behaviors 

Quantitativeness 

Unsealed  Graphs 

Supporting  Data 

Q  No  Validation 

|  [  Validation  with  Questionable  Results 
□  Validated 

Comments 


K-295 


Reference 

Siegel,  et.  al.,  1977 


95 


Appropriate 


Dependent  Variables 

Information  loss 


Independent  Variables 

Nuufcer  of  errors  made  (simulated) 
Length  of  message 
Importance  of  message 


Page 

42 

Behaviors 


Quantitativeness 

Nominal 

Supporting  Data 

PI  No  Validation 

Q  Validation  with  Questionable  Results 
□  Validated 

Comments 


K-2  96 


Reference 

Siegei,  et.  a!.,  1977 


Appropriate 

J 

Dependent  Variables 

Efficiency 

-  4  measures 

• 

j 

1 

Thoroughness 

Responsiveness 

j 

- 

Completeness 

Accuracy 

! 

Independent  Variables 


Page 

45  -  46 

Behaviors 


Quanti tativeness 

Functions 

Supporting  Data 

|~~[  No  Validation 

j  |  Validation  with  Questionable  Results 
□  Validated 

Comments 


See  these  f)ur  variables 


Reference 


95 


Siegel,  et.  al.,  1977 


Appropriate 

Yes 


Dependent  Variables 

Thoroughness 


Independent  Variables 

Number  of  message  blocks  completed 

Number  of  possible  blocks  which  could  be  completed 


Page 

45 


Behaviors 

Quantitativeness 

Functions 

Supporting  Data 

□ 

No  Validation 

□ 

Validation  with  Questionable  Results 

□ 

Validated 

Comments 


K-298 


Reference 

Siegel,  ut.  al..  1977 


Appropriate 

Yes 

Dependent  Variables 
Completeness 


Independent  Variables 

_  ^  -  Number  of  successes 

*  E  perf  (M)  =  c _ _ 

Number  of  successes  and  Number  of  fai 


Page 

45,  118 

Behaviors 

Quantitativeness 

Supporting  Data 


Comments 


□  Ho  Validation 

[H  Validation  with  Questionable  Results 

□  Validated 


Appropriate 

Yes 

Dependent  Variables 

Responsiveness 


Independent  Variables 


Behaviors 


,|j( 


Average  message  processing  time 
600  seconds 


Quantitativeness 

Functions 

Supporting  Data 


Comments 


□  No  Validation 

□  Validation  with  Questionable  Results 

□  Validated  I 


K-300 


jfl 
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**  /■ 


£ 


,  J* 
,V 


Reference 


Siegel,  et.  al . ,  1977 


Appropriate 

Yes 


Dependent  Variables 
Accuracy 


Independent  Variables 


•■( 


Total  information  loss 


Number  of  messages  completed 


) 


Page 


45 


Behaviors 


Quantitativeness 

Functions 


Supporting  Data 


Q  No  Validation 

I"!  Validation  with  Questionable  Results 
□  Validated 


Comments 


K-301 


Appropriate 

Yes 

Dependent  Variables 

Percentage  of  time  worked 

Independent  Variables 

Operator  skill 


Page 

59 

Behaviors 

Quantitativeness 

Scaled  Graphs 

Supporting  Data 

Q  No  Validation 

!  |  Validation  with  Questionable  Results 
□  Validated 

Comments 

Simulated  results 


K-302 
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Reference 


Siegel,  et.  al.,  1977 


Dependent  Variables 

Performance  time  per  message 


Independent  Variables 


Team  skill  level 
5  segments 


Quant i tativenes  s 

Scaled  Graphs 

Supporting  Data 

n  No  Validation 

n  Validation  with  Questionable  Results 
I"*!  Validated 

Comments 


tv 


K-304 


Reference 


Siegei,  et.  al.,  1977 


Appropriate 

Yes 


Dependent  Variables 

Mean  number  of  messages  carried  over  to  the  next  hour  and  completed 
within  the  hour 


Independent  Variables 
I  l1  Skill 

j  Two  job  positions 


63  -  64 

Behaviors 

Quintitativeness 

Scaled  Graphs 

Supporting  Data 


j^~]  No  Validation 

|  [  Validation  with  Questionable  Results 
□  Validated 


Comments 


Simulation  data 


K-305 


y  2  ✓  ' 


Reference 


Siegel,  et.  al.,  1977 


Appropriate 


Dependent  Variables 


Error 


Independent  Variables 
Skill 

No  relationship 


Behaviors 


Quanti tativenes  s 


Supporting  Data 


H  No  Validation 

n  Validation  with  Questionable  Results 
□  Validated 


Cements 


K-306 


Reference 

Siegel,  et.  al.,  197/ 

Appropriate 

Dependent  Variables 

Mean  time  used 

Independent  Variables 

Segment 
Operator  mix 


Page 

69 

Behaviors 

Quantitativeness 

Scaled  Graphs 
Supporting  Data 

{~~|  Ho  Validation 

I  1  Validation  with  Questionable  Results 
□  Validated 


Comments 


Reference 

Siegel,  et.  al.,  1977 


mWTOmTnWM 

95 


Appropriate 


i>ependent  Variables 

Percent  of  time  worked 


Independent  Variables 

Operator  Mix  -  three  officers/  three  specs. 

two  officers/  four  specs. 

Skill  level 


Page 

67 

Behaviors 


Quantitativeness 

Scaled  Graphs 

Supporting  Data 


□  No  Validation 

□  Validation  with  Questionable  Results 

□  Validated 

Comments 


K-308 


'  Reference 


Siegel,  et.  al.,  1977 


95 


r 


Appropriate 

Yes 

Dependent  Variables 

Percent  of  time  worked 

Time 

-  ; 

Independent  Variables 


Message  workload 


Page 


71  -  73 


Behaviors 


Quantitativeness 

Scaled  Graphs 

Supporting  Data 

□  No  Validation 

I  |  Validation  with  Questionable  Results 

□  Validated 

Comments 


K-309 


’  Reference 

Siegel,  et.  al.,  1577 


Appropriate 

Medium 


Dependent  Variables 

Performance  adjustment 


Independent  Variables 

Aspiration 

Current  performance  level 


Page 

74  -  75 


Behaviors 


Quantitativeness 

Scaled  Graphs 

Supporting  Data 

□  No  Validation 

□  Validation  with  Questionable  Results 
|  |  Validated 

(-  _ 


Comments 


'  Reference 


Siegel,  A. I.,  Wolf,  J.J.,  and  Liahy,  W.R.  A  digital  simulation  model 
of  message  handling  in  the  Tactical  Operations  System:  II.  Extensions 
of  the  model  for  interactivity  with  subjecst  and  emperimenters .  Alexandria,  V, 
U.S.  Arim  Research  Institute  for  the  Behavioral  and  Social  Sciences,  Technical 
Report  TR-77-A24,  October  1977,  Contract  No.  DAHC19-72-C00003.  ADA046407. 


Appropriate 

Conditional 


Dependent  Variables 


Independent  Variables 


Page 

Behaviors 

Quantitativeness 

Supporting  Data 

Ip  No  Validation 

□  Validation  with  Questionable  Results 

□  Validated 

Comments 

If  #89  is  used,  see  this  for  important  revisions  to  responsiveness, 
effectiveness,  multiple  input  messages,  undetected  errors,  and  stress. 


K— 31 1 


Reference 

Hendrick,  C.,  Mills,  J.,  and  Kiesler,  C.A.  Decision  time  as  a 
function  of  the  number  and  complexity  of  equally  attractive  altemativ 
Journal  of  Personality  and  Social  Psychology,  1968,  £,  313  -  318. 


Appropriate 

Yes 


! 

| 

» 

* 


Dependent  Variables 

Decision  time 


|  Independent  Variables 

j 

Choice  set  (2,  4] 

Number  of  dimensions  (1,  many) 
I  First  vs.  second  choice 


Page 


316 


Behaviors 

Decision  making 


Quantitativeness 

Table 

Supporting  Data 

1 

D 

No  Validation 

□ 

Validation  with  Questionable  Results 

E3 

Validated 

Comments 


Reference 

Andrews,  R.S.  Jr.,  and  Ringel,  S.  Certitude  judgements  and  accuracy  d 
information  assimilation  from  visual  displays.  U.S.  Army  Personnel 
Research  Office,  Technical  Research  Note  145,  May  1964 


Appropriate 

Yes 


Dependent  Variables 

Certitude  (certainty  rating  1  to  7) 
Accuracy  of  detection 


Independent  Variables 

Number  symbols  removed  (2,  4,  6,  8) 
Amount  of  targets  (12,  16,  20,  24) 


Page  g 

Behaviors  Decision  making 
Discrimination 
Visual  memory 

Quantitativeness 

Scaled  Graphs 

Supporting  Data 

□ 

No  Validation 

□ 

Validation  with  Questionable  Results 

S3 

Validated 

Comments 


Page 

20 

Behaviors 

Decision  Making 

ii1 

_  - .  --  ■  -  -  -- 

Quantitativeness 

Table  1  ! 

i 

i 

Supporting  Data 

□  No  Validation 

I  |  Validation  with  Questionable  Results 
jxj  Validated 

Comments 


K— 314 


■  Reference 


Andrews,  et.  al.,  1964 

Appropriate 
Yes 

Dependent  Variables 
Certitude 

Independent  Variables 

Number  synfcols  removed  (2,  4,  6,  8) 


Page 

13 

Behaviors  Decision  Making 
Discrimination 
Visual  Memory 

Quantitativeness 

Scaled  Graphs 

Supporting  Data 

□  No  Validation 

□  Validation  with  Questionable  Results 


Ext  Validated 


i 

7 

.7 

J 


■4 

t 


1  Reference 

Andrews,  et.  al.,  1964 


Appropriate 

Yes 

Dependent  Variables 
Certitude 


Independent  Variables 

Amount  of  targets  (12,  16,  SO,  24) 


» 

T 


\ 


Page 

12 

Behaviors 

Decision  Making 

Discrimination 

Visual  Memory 

Quantitativeness 

Scaled  Graphs 

Supporting  Data 

]~~~1  No  Validation 

I  |  Validation  with  Questionable  Results 

fx33  Validated 

Comments 


K-316 


*  Reference  j 

Williams,  c.  Human  performance  simulation.  Bolling  AFB,  Washington,  D.C 
Air  Force  Office  of  Scientific  Research,  Technical  Rej>ort  AFOSR-TR-78-123 
August  1977.  Contract  Wo. ’ F44620-76-C-001 3.  ADA05894U  •; 


Appropria\  e 

Lov; 


Independent  Variables 


S-S  Translation 
S-R  Translation 
Response  initiation 
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MOPADS  FINAL  REPORT: 

A  DATA  BASE  FOR  QUANTITATIVE  HUMAN 
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<Chl*r 


TABLE  OF  CONTENTS 


Section  Page 

LIST  OF  TABLES  vi 

I.  INTRODUCTION  1 

II.  EXAMPLE  OF  ENTERING  ARTICLES  12 

III.  EXAMPLE  OF  DATA  BASE  ANALYSIS  18 


IV.  EXAMPLE  OF  INDEPENDENT  VARIABLE  REFERENCE  COUNT  24 

1 

Appendix  A-ENTER  ARTICLES  Computer  Program  Printout  29 

Appendix  B-DATA  BASE  ANAYLSIS  Computer 

program  Printout  *  I1  33 

Appendix  C-IV  REF  COUNT  Computer  Program  Printout  .  37 


LIST  OF  TABLES 


Table  Page 

1  Independent  Vanables-Aptltude  3 

2  Independent  Variables-Learning/Practice  4 

3  Independent  Variables-Envlronmental  5 

4  Independent  Varlables-Task  Strategy/Procedures  6 

5  Independent  Varlables-Task  Man/Machine  Interface  7 

6  Printout  of  Skills  Data  File  .  9 


L-3 


IWK 


~  -V*.  J.  TTTyrTTTTV: T* ?! ’9TrT^rTwT9rvTr; yj rj TP T??* 


1~ Introduction 

To  facilitate  the  development  and  analysis  of  a  data  base  on  models 
of  human  performance,  a  set  of  computer  programs  and  a  computerized  data  base 
were  developed.  Through  the  use  of  these  programs,  human  performance  models 
can  easily  be  stored  into  the  data  base,  and  later  analyzed  in  any  number  of 
different  ways.  This  approach  was  believed  to  be  more  practical  than  hand- 
recording  this  data  base.  First,  computer  input  of  the  data  would  be  less 
time  consuming  than  hand  recording  if  a  well  designed  input  program  was  used. 
Second,  each  computer  analysis  requires  only  simple  programming,  whereas 
manual  manipulation  would  require  slower  hand  calculations  and  data  restructuring 
Finally,  additions  or  modifications  to  the  data  base  would  be  less  cumbersome 
using  a  computerized  data  base. 

Currently,  three  program  are  available  to  create,  modify,  and 
analyze  the  data  bases.  They  are  currently  on  an  APPLE  II  plus  microcomputer 
with  48  K  RAM.  These  programs  and  brief  descriptions  are  as  follows: 

1.  ENTER  ARTICLES  -  This  program  allows  the  entry  of  models  from 
articles  in  the  open  literature  into  the  computer  data  base. 

\,  2.  DATA  BASE  ANALYSIS  -  This  program  permits  an  examination  of 

the  data  base  to  determine  independent  variables  which  are 
linked  to  skill  categories,  number  or  times  the  link  is 
referenced,  and  articles  referencing  skill  categories. 

3.  IV  REF  COUNT  -  This  program  counts  the  total  number  of  times 
that  all  independent  variables  are  referenced  in  the  data  base. 

Sample  on  each  of  these  programs  will  be  provided  in  the  following  three 
sections  of  this  report.  Printouts  of  the  three  programs  are  presented  in 
Appendices  A,  B,  and  C.  Nine  data  files  are  required  to  support  these 
programs.  Six  of  them  represent  the  independent  variables,  one  of  them 
represents  the  skills  taxonomy,  and  one  of  them  represents  the  literature 
data  base. 
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The  first  five  files  include  all  independent  variable  titles,  as  noted  below, 
and  the  sixth  file  (IND  VARS-10)  provides  some  information  required  by  the 
programs  for  file  manipulation. 

IND  VARS- 1  -  Aptitude 

IND  VARS- 2  -  Learning  or  practice 

IND  VARS- 3  -  Environment 

IND  VARS- 4  -  Task  procedures  and/or  strategies 
IND  VARS- 5  -  Human/machine  interface 

IND  VARS-iO-  This  file  includes  the  total  number  of  titles  in 
each  of  the  five  other  files. 


The  five  files  with  independent  variable  titles  have  been  categorized 
in  the  above  manner  to  provide  an  intuitive  structure  for  the  analyst.  If  the 
independent  variables  were  stored  in  an  arbitrary  manner,  alphabetically  for 
example,  an  analyst  might  look  for  a  variable  such  as  "screen  clutter"  under 
any  number  of  titles  such  as  "number  of  targets  per  unit  area"  or  "display 
clutter."  The  process  of  searching  for  the  particular  variable  of  interest 
would  be  difficult.  Given  the  above  structure,  however,  the  analyst  can 
reasonably  assume-  that  it  is  a  "human/machine  interface"  variable  and  search 
for  it  within  that  file.  The  number  of  independent  variable  titles  within 
each  file  are  relatively  small;  21,  12,  12,  33,  and  42  for  files  IND  VARS- 1,2, 
3,4,  and  5,  respectively.  Printouts  of  the  data  in  each  of  these  files  as 
of  this  report  date  are  presented  in  Tables  1  through  5. 

Tnese  files  were  structured  to  be  dynamic.  In  other  words,  every 
time  a  model  is  encountered  in  which  a  new  independent  variable  is  presented, 
this  new  variable  should  be  added  to  these  data  files.  Consequently,  as  the 
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Table  1 

-  INDEPENDENT  VARIABLES-  APTITUDE 


RISK  ACCEPTANCE 

INTELLIGENCE 

AGE 

OPERATOR  TYPE 
SENSE  OF  DIRECTION 
WILLINGNESS  TO  TAKE  RISKS 
OBSERVATION  NOISE 
PERCEPTUAL  TIME  DELAY 
MOTOR  NOISE 

OPERATOR  GAIN  (BJ<9  COMBINED) 
GENERAL  PROFICIENCY  FACTOR 
THRESHOLD  CONTRAST 
ASPIRATION  LEVEL 
OPERATOR  PRECISION 
TEAM  SKILL  LEVEL 
TRACKING  ABILITIES 
MOTIVATION  LEVEL 
VISUAL  ACUITY 
GENERAL  APTITUDE  SCORE 
MORALE  LEVEL 
LEADERSHIP  ABILITY 
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Table  2 


INDEPENDENT  VARIABLES-LEARNING/PRACTICE 


#  PRACTICE  TRIALS 

TIME  SINCE  LAST  PRACTICED 

AMOUNT  OF  OVERLEARNING 

TIME  SINCE  INITIALLY  LEARNED 

TRAINING  EMPHASIS < SPEED  VS  COORDINATION) 

AMOUNT  OF  TRAINING 

PRESENCE  OF  FEEDBACK 

NUMBER  OF  CORRECT  CHOICES 

MASSED  VS  DISTRIBUTED  PRACTICE 

AMOUNT  OF  INITIAL  TRAINING 

TYPE  OF  FEEDBACK  j 

#  SUCCESSFUL  TRIALS 


I ' 
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Table  3 


INDEPENDENT  VAR TABLES- ENVIRONMENTAL 


AMBIENT  TEMPERATURE 
SKIN  TEMPERATURE 
TIME  OK  DAY 
NOISE  LEVEL 
LIGHT  LEVEL 

DISTANCE  BETWEEN  COMMUNICATORS 

TYPE  OF  NOISE 

WET  BULB  TEMPERATURE 

VIBRATION  LEVEL 

EFFECTIVE  TEMPERATURE 

GENERAL  STRESS 

FLASH  INTENSITY 


«.vvsv‘ 


Table  4 


INDEPENDENT  VARIABLES-TASK.  STRATEGY 


INFORMATION  QUANTITY  (SAMPLE  SI2E) 

TIME  SPENT  ON  TASK 

ORGANIZATION  PERFORMING (SQUAD 

DAYS  SPENT  ON  TASK 

WORK/REST  CYCLE 

SESSION  NUMBER (SHORT  SESSIONS) 

NUMBER  OF  POSSIBLE  RESPONSES 
MONOCULAR  VS  BINOCULAR  VIEWING 
SLEEP  DEPRIVATION 
NUMBER  OF  TASKS  PERFORMED  AT  ONCE 
HOURS  WORKED  PER  WEEK 
IMPORTANCE  OF  TASK  PARAMETERS 
PHYSICAL  ENERGY  COST  OF  TASK 
NUMBER  OF  DISPLAYS  MONITORED 
SIGNAL  RATE 

DRUG  USAGE  % 

TIME  BETWEEN  STIMULUS  AND  RESPONSE 

PERCEIVED  PROBABILITY  OF  AN  EVENT 

PERCEIVED  COST  OF  ALTERNATE  DECISIONS 

PROBABILITY  OF  AN  EVENT 

MATERIAL  STRENGTH  RATIO-FRIEND /FOE 

PERSONNEL  STRENGTH  RATIO  FRIEND/FOE 

ENEMY  TERRAIN  ADVANTAGE 

UNIT  RESUPPLY  CONDITIONS 

TEAM  STRUCTURE 

NUMBER  OF  OBSERVERS 

OBSERVER  SCAN  PATTERNS 

SPEED  OF  TASK  STRESS 

BACKLOG  OF  WORK 

CONSISTENCY  OF  DATA 

OBSERVATION  TIME  PER  DISPLAY 

HISTORY  OF  SYSTEM  STATES 

URGENCY  OF  TASK 


» 
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Table  5 


INDEPENDENT  VARIABLE5-TASK  1AN/MACJIINE  INTERFACE 

TARGET  SIZE 

TARGET  BACKGROUND  TYPE 

BACKGROUND  LUM I NANCE 

PERCENT  TARGETS  AMONG  SIGNALS 

TARGET  BRIGHTNESS 

DISTANCE  TARGET  HAS  TRAVELED 

RELATIVE  DIRECTION  OF  TARGET  MOTION 

TARGET  SPEED 

TARGET  TYPE 

CONTRAST  RATIO  (TARGET / BACKGROUND ) 

TARGET  ANGLE  RELATIVE  TO  FOVEA 
BLINDING  FLASH  ENERGY 
NUMBER  OF  CUES  FOR  A  SIGNAL 
COMMUNICATION  MODE 
CONTROL  SENSITIVITY 
CONTROL  DYNAMICS  (ORDER) 

TARGET  MOVEMENT  BAND WITH 
PROCESS  NOISE 
SEARCH  AREA 
TARGET  DISTANCE 

METEOROLOGICAL  RANGE (VISIBILITY) 

TARGET  HORIZONTAL  DISTANCE 

VISUAL  AIDING 

TARGET  COLOR 

STIMULUS  MODE 

RESPONSE  MODE 

LENGTH  OF  EARLY  WARNING 

DISPLAY  TYPE 

DISPLAY  RESOLUTION 

DISPLAY  CLUTTER 

NUMBER  OF  DISPLAY  COLORS 

MESSAGE  LENGTH 

MESSAGE  IMPORTANCE 

NUMBER  OF  SIGNAL /TARGET  DIMENSIONS 

SIGNAL  DURATION 

INTER  DISPLAY  ANGLE 

DIRECTION  OF  ILLUMINATION  SOURCE 

SCENE  COMPLEXITY 

TARGET  POSITION  ON  DISPLAY 

TASK  TYPE (PROCEDURAL 

SIGNAL  AMPLITUDE 

STEP  VS  RAMF  FAILURE 
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overall  literature  data  base  was  being  entered  into  the  computer,  new 
independent  variables  were  constantly  being  added.  This  was  accomplished 
through  the  ENTER  ARTICLES  program. 

The  SKILLS  data  file  included  the  titles  of  all  skills  in  the  skill 
taxonomy.  These  skills  represented  the  general  nature  of  the  dependent 
variables  included  in  each  model.  This  file  was  not  intended  to  be  dynamic 
since  the  skills  taxonomy  was  believed  to  be  comprehensive.  There  were  some 
general  skill  titles  added  to  include  models  with  poorly  defined  dependent 
variables.  Table  6  presents  a  printout  of  this  file. 

The  filial  data  file  is  (Skills  by  Independent  Variables).  This  incl 
the  information  used  to  identify  the  models  presented  in  the  literature.  Thi 
file  is  created  and  added  onto  by  the  ENTER  ARTICLES  program.  Each  record 
in  the  file  includes  the  following  information: 

1.  The  number  of  the  skill  being  modeled. 

2.  The  number  of  the  independent  variable  file  (1  to  5). 

3.  The  number  of  the  independent  variable  within  the  file  type 

identified  above. 

4.  The  degree  of  quantitative  development  of  the  model  (ranging 
from  0  to  3,  0  *  nominal,  3  ■  specific  function  identified). 

5.  The  number  of  skill  categories  linked  to  one  model. 

The  fifth  piece  of  information  above  is  relevant  when  the  specific  model 
presented  in  the  literature  corresponds  to  several  skills.  For  example,  if  a 
article  presented  a  model  for  detection  and  identification  time,  but  did  not 
separate  the  total  time  into  a  detection  component  and  identification 
component,  this  model  would  be  stored  on  the  records,  once  with  the  skill 
identified  as  detection  and  once  with  the  skill  as  identification.  However, 
the  fifth  data  point  on  each  record  would  be  a  "2",  indicating  that  this  modi 
was  stored  in  another  location  under  a  different  skill  title.  This  informati 
was  included  in  the  data  base  so  models  with  multiple  skills  could  be  elimina 
from  analysis  if  desired'. 
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Table  6 

PRINTOUT  OF  SKILLS  DATA  FILE 

GENERAL  BEHAVIORS 
VIBILANCE 

PROBABILITY  ESTIMATION 

TIME  ESTIMATION 

HUMAN  RELIABILITY  ASSESSMENT 

MEANINGFUL  MEMORY  ABILITY 

VERBAL  KNOWLEDSE 

WORD  FLUENCY 

NUMERICAL  ABILITY 

CONCEPT  FLUENCY 

DISCOVERY  OF  PRINCIPLES 

FLEXIBILITY 

SYMBOL  MANIPULATION 

DECISION  MAKINS 

INTELLEBENCE 

FINE  MANIPULATIVE  ABILITIES 

POSITION  ESTIMATION 

BROSS  MANIPULATIVE  ABILITIES 

CONTROL  PRECISION 

SPEED  OF  ARM  MOVEMENT 

MULTILIMB  COORDINATION 

POSITION  REPRODUCTION 

MOVEMENT  ANALYSIS 

MOVEMENT  PREDICTION 

ACCELERATION  CONTROL 

REACTION  TIME 

TRACK I NS 

DETECTION 

DISCRIMINATION  ABILITIES 
TIME  SHARING 

CLOSURE  ABILITIES (PERCEPTUAL) 

AUDITORY  ABILITIES 
SPATIAL  ABILITIES— OR I ENTAT I ON 
SPATIAL  AB I L I T I ES-  V I SUAL I Z AT I ON 
ASSOCIATE  MEMORY-ROTE  MEMORY 
ASSOCIATE  MEMORY-MFANINGFUL  MEMORY 
MEMORY  SPAN-SHORT  TERM  MEMORY 
MEMORY  SPAN-INTEGRATION  OF  INFORMATION 
VISUAL  MEMORY 

EXPLOSIVE  STRENGTH-GENERAL 
EXPLOSIVE  STRENGTH-LEG  EMPHASIS 
EXPLOSIVE  STRENGTH-UPPER  BODY  EMPHASIS 
STATIC  STRENGTH-ARM/HAND/SHOULDER 
STATIC  STRENGTH-LEG/TRUNK 
DYNAMIC  STRENGTH-ARMS 


Table  6  (continued) 
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DYNAMIC  STRENGTH-LEGS 
TRUNK  STRENGTH 
EXTENT  FLEXIBILITY 
DYNAMIC  FLEXIBILITY 
GROSS  BODY  EQUILIBRIUM 
BALANCE- VISUAL  CUES 
GROUP  COOPERATION 
GROUP  COMMUNICATION 
LEADERSHIP 

GENERAL  COGNITIVE  ABILITIES 
GENERAL  PHYSICAL  ABILITIES 


i 
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In  the  following  three  sections,  examples  are  presented  of  interactio? 
with  the  three  sets  of  computer  programs,  ENTER  ARTICLES,  DATA  BASE  ANALYSIS, 
and  IV  REF  COUNT.  In  these  sections,  all  input  by  the  analyst  are  underlined. 
All  other  information  is  printed  by  the  computer. 


'2-Example  of  entering  articles 


Below  Is  an  example  of  an  interaction  between  the  analyst  and  the 
computer  program  ENTER  ARTICLES.  The  example  illustrates  an  analyst 
attempting  to  add  a  model  from  article  number  100,  skill  number  14 
(Decision  Making),  and  an  initial  attempt  to  link  this  model  to  the 
independent  variable  Visual  Acuity.  After  this  first  attempt,  the  analyJ 
decides  to  create  a  new  independent  variable,  then  again  changes  his 
mind  ar.d  decides  not  to  add  the  model  at  all. 

NOTE:  All  information  entered  by  the  analyst  is  underlined. 

1RUN  ENTER  ARTICLES 


DO  YOU  WANT  TO  ADD  A  NEW  ARTICLE  TO 
THE  DATA  BASE?  <Y/N>  Y 
ENTER  ARTICLE  NUMBER- ICO 
ENTER  QUANTITATIVENESS  INDEX  <0-3>-2. 

DO  YOU  NEED  A  SKILL  CATEGORY  MENU?  (Y/N)  Y 

1  GENERAL  BEHAVIORS 

2  VIGILANCE 

3  PROBABILITY  ESTIMATION 

4  TIME  ESTIMATION 

5  HUMAN  RELIABILITY  ASSESSMENT 

6  MEANINGFUL  MEMORY  ABILITY 

7  VERBAL  KNOWLEDGE 
B  WORD  FLUENCY 

9  NUMERICAL  ABILITY 

10  CONCEPT  FLUENCY 

11  DISCOVERY  OF  PRINCIPLES 

12  FLEXIBILITY 

13  SYMBOL  MANIPULATION 

14  DECISION  MAKING 

15  INTELLEGENCE 

16  FINE  MANIPULATIVE  ABILITIES 

17  POSITION  ESTIMATION 

18  GROSS  MANIPULATIVE  ABILITIES 

HIT  ’SPACE’  KEY  TO  CONTINUE 
ANY  OTHER  KEY  TO  EXIT  MENU 


(SPACE  KEY) 
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mm  s  .v*ra  at  aanauvi 


is  iPBiBVSgfi^SQ&iENT 

21  MULTILIMB  COORDINATION 

22  POSITION  REPRODUCTION 

23  MOVEMENT  ANALYSIS 

24  MOVEMENT  PREDICTION 

25  ACCELERATION  CONTROL 

26  REACTION  TIME 

27  TRACKING 

28  DETECTION 

29  DISCRIMINATION  ABILITIES 

30  TIME  SHARING 

31  CLOSURE  ABILITIES (PERCEPTUAL) 

32  AUDITORY  ABILITIES 

33  SPATIAL  ABILITIES-ORIENTATION 

34  SPATIAL  ABILITIES— VISUALIZATION 

35  ASSOCIATE  MEMORY-ROTE  MEMORY 

36  ASSOCIATE  MEMORY— MEAN I NGFUL  MEMORY 

HIT  'SPACE'  KEY  TO  CONTINUE 
ANY  OTHER  KEY  TO  EXIT  MENU 

(SPACE  KEY) 
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37  MEMORY  SPAN-SHORT  TERM  MEMORY 

38  MEMORY  SPAN- INTEGRATION  OF  INFORMAT I 

39  VISUAL  MEMORY 

40  EXPLOSIVE  STRENGTH-GENERAL 

41  EXPLOSIVE  STRENGTH-LEG  EMPHASIS 

42  EXPLOSIVE  STRENGTH-UPPER  BODY  EMPHAS 

43  STATIC  STRENGTH-ARM/HAND/SHOULDER 

44  STATIC  STRENGTH-LEG/TRUNK 

45  DYNAMIC  STRENGTH-ARMS 

46  DYNAMIC  STRENGTH-LEGS 

47  TRUNK  STRENGTH 

48  EXTENT  FLEXIBILITY 

49  DYNAMIC  FLEXIBILITY 

50  GROSS  BODY  EQUILIBRIUM 

51  BALANCE- VISUAL  CUES 

52  GROUP  COOPERATION 

53  GROUP  COMMUNICATION 

54  LEADERSHIP 

HIT  'SPACE’  KEY  TO  CONTINUE 
ANY  OTHER,  KEY  TO  EXIT  MENU 
(SPACE  KEY) 

55  GENERAL  COGNITIVE  ABILITIES 

56  GENERAL  PHYSICAL  ABILITIES 

ALL  SKILL  CATEGORIES  DISPLAYED 
ENTER  SKILL  CATEGORY  NUMBER  OR 
HIT  RETURN  IF  ALL  SKILL  CATEGORIES 
HAVE  BEEN  ENTERED-  14 
ENTER  NEXT  SKILL  CATEGORY 

DO  YOU  NEED  A  SKILL  CATEGORY  MENU?  <Y/N>  N 
ENTER  SKILL  CATEGORY  NUMBER  OR 
HIT  RETURN  IF  ALL  SKILL  CATEGORIES 
HAVE  BEEN  ENTERED-  (RETURN  KEY) 

WHAT  TYPE  OF  VARIABLE  IS  INDEPENDANT 
VARIABLE  NUMBER  1 

APTITUDE=1 
LEARNING/PRACTICE=2 
ENVIR0NMENTAL=3 
TASK-PROCEDURE /STRATEGY® 4 
TASK-MAN/MACHINE  INTERFACE=5 

HIT  'RETURN'  IF  ALL  VARIABLES  ARE  IN 
ENTER  '9'  TO  SKIP  THIS  ARTICLE  1 
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1  RISK  ACCEPTANCE 

2  INTELLIGENCE 

3  AGE 

4  OPERATOR  TYPE 

5  SENSE  OF  DIRECTION 

6  WILLINGNESS  TO  TAKE  RISKS 

7  OBSERVATION  NOISE 

8  PERCEPTUAL  TIME  DELAY 

9  MOTOR  NOISE 

10  OPERATOR  GAIN  <e&9  COMBINED) 

11  GENERAL  PROFICIENCY  FACTOR 

12  THRESHOLD  CONTRAST 

13  ASPIRATION  LEVEL 

14  OPERATOR  PRECISION 

15  TEAM  SKILL  LEVEL 

16  TRACKING  ABILITIES 

17  MOTIVATION  LEVEL 

18  VISUAL  ACUITY 
HIT  RETURN  FOR  MORE 

ENTER  VARIABLE  NUMBER  IF  FOUND 
ENTER  ’A’  IF  NEW  VARIABLE  IS  REQUIRED 
ENTER  ' M'  TO  RETURN  TO  VAR  TYPE  MENU 
ENTER  ' R'  IF  MENU  MUST  DE  REVIEWED 


SKILL=14  IND  VAR*=18  ARTICLED 00 
ALL  INFORMATION  CORRECT?  <Y/N>  N 
ENTER  VARIABLE  NUMBER  IF  FOUND 
ENTER  'A’  IF  NEW  VARIABLE  IS  REQUIRED 
ENTER  'M-  TO  RETURN  TO  VAR  TYPE  MENU 
ENTER  ' R'  IF  MENU  MUST  BE  REVIEWED  M 

WHAT  TYPE  OF  VARIABLE  IS  INDEPENDANT 
VARIABLE  NUMBER  1 

APTITUDE1*  1 
LEARNING/PRACTICE=2 
ENVIR0NMENTAL=3 
TASK-PROCEDURE /STRATEGY=4 
TASK-MAN/MACHINE  INTERFACED 

HIT  " RETURN'  IF  ALL  VARIABLES  ARE  IN 
ENTER  ' 9”  TO  SKIP  THIS  ARTICLE  I 
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1  AMBIENT  TEMPERATURE 

2  SKIN  TEMPERATURE 

3  TIME  OF  DAY 

4  NOISE  LEVEL 

5  LIGHT  LEVEL 

6  DISTANCE  BETWEEN  COMMUNICATORS 

7  TYPE  OF  NOISE 

8  WET  BULB  TEMPERATURE 

9  VIBRATION  LEVEL 

10  EFFECTIVE  TEMPERATURE 

1 1  GENERAL  STRESS 

12  FLASH  INTENSITY 

ALL  VARIABLES  DISPLAYED 

ENTER  VARIABLE  NUMBER  IF  FOUND 
ENTER  *  A’  IF  NEW  VARIABLE  IS  REQUIRED 
ENTER  * M’  TO  RETURN  TO  VAR  TYPE  MENU 
ENTER  ’  R’  IF  MENU  MUST  BE  REVIEWED  A 

ENTER  NAME  OF  NEW  INDEPENDANT  VARIABLE 
ENTER  ’SPACE'  TO  RETURN  TO  MENU  * 
(SPACE  BAR) 

1  AMBIENT  TEMPERATURE 

2  SKIN  TEMPERATURE 

3  TIME  OF  DAY 

4  NOISE  LEVEL 

5  LIGHT  LEVEL 

a  DISTANCE  BETWEEN  COMMUNICATORS 

7  TYPE  OF  NOISE 

8  WET  BULB  TEMPERATURE 

9  VIBRATION  LEVEL 

10  EFFECTIVE  TEMPERATURE 

11  GENERAL  STRESS 

12  FLASH  INTENSITY 


f 

f 

1 

' 

f 


}LL  VARIABLES  DISPLAYED 

ENTER  VARIABLE  NUMBER  IF  FOUND 
:NTF.R  ’A’  IF  NEW  VARIABLE  IS  REQUIRED 
-NTER  ’M’  TO  RETURN  TO  VAR  TYPE  MENU 
ENTER  ’R’  IF  MEN'J  MUST  BE  REVIEWED  51 


i» 

V 

s 

» 


< 
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WHAT  TYPE  OF  VARIABLE  IS  INDEPENDANT 
VARIABLE  NUMBER  1 

APTITUDE-1 
LEARNING/PRi'CTICE-2 
ENV I RUNMENT  Ai_-3 
TASK-PROCEDURE /STRATEGY-4 
TASK-MAN/ MACHINE  INTERFACE-5 

HIT  *  RETURN'  IF  ALL  VARIABLES  ARE  IN 
ENTER  '9'  TO  SKIP  THIS  ARTICLE  (RETURN  KEY) 
DO  YOU  WANT  TO  ADD  A  NEW  ARTICLE  TO 
THE  DA-  A  BASE?  <Y/N>  N 

DO  YOU  JANT  TO  QUIT?  (Y/N)V 


NOTE:  In  this  example,  no  articles,  models,  or  new  independent 

variables  were  added  to  the  data  base.  These  additions  were 
avoided  by  respondidg  "NO"  to  the  question  "IS  THIS  CORRECT?". 
New  data  could  have  been  added  simply  by  responding  "YES" 
to  this  question. 


* 
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3-Exa^ple  of  Data  Pase  /Wlysis 


Below  Is  an  example  of  the  interaction  between  the  analyst  and 
the  DATA  BASE  ANALYSIS  computer  program.  This  example  shows  the 
analyst  looking  at  the  combination  of  skills  DETECTION  and  DISCRIM  I  NAT 
Additionally,  he  only  warts  to  review  those  models  which  were  tied 
exclusively  (i.e.,  unambiguously)  to  cither  detection  or  discrirainatio 


3 RUN  DATA  BASE  ANALYSIS, D1 


DO  YOU  NEED  A  SKILL  CATEGORY  MENU?  (Y/N)  I 

1  GENERAL  BEHAVIORS 

2  VIGILANCE 

3  PROBABILITY  ESTIMATION 

4  TIME  ESTIMATION 

5  HUMAN  RELIABILITY  ASSESSMENT 

6  MEANINGFUL  MEMORY  ABILITY 

7  VERBAL  KNOWLEDGE 

8  WORD  FLUENCY 

9  NUMERICAL  ABILITY 

10  CONCEPT  FLUENCY 

11  DISCOVERY  OF  PRINCIPLES 

12  FLEXIBILITY 

13  SYMBOL  MANIPULATION 

14  DECISION  MAKING 

15  INTELLEGENCE 

16  FINE  MANIPULATIVE  ABILITIES 

17  POSITION  ESTIMATION 

IB  GROSS  MANIPULATIVE  ABILITIES 

HiT  *  SPACE"  KEY  TO  CONTINUE 
ANY  OTHER  KEY  TO  EXIT  MENU 


(SPACE  KEY] 


19  CONTROL  PRECISION 

20  SPEED  OF  ARM  MOVEMENT 

21  MULTILIMB  COORDINATION 

22  POSITION  REPRODUCTION 

23  MOVEMENT  ANALYSIS 

24  MOVEMENT  PREDICTION 

25  ACCELERATION  CONTROL 

26  REACTION  TIME 

27  TRACK I NO 

28  DETECTION 

29  DISCRIMINATION  ABILITIES 

30  TIME  SHARING 

31  CLOSURE  ABILITIES (PERCEPTUAL) 

32  AUDITORY  ABILITIES 

33  SPATIAL  ABILITIES-ORIENTATION 

34  SPATIAL  ABILITIES— VISUALI ZATION 

35  ASSOCIATE  MEMORY-ROTE  MEMORY 

36  ASSOCIATE  MEMORY-MEANINGFUL  MEMORY 

HIT  'SPACE'  KEY  TO  CONTINUE 
ANY  OTHER  KEY  TO  EXIT  MENU 

(SPACE  KEY) 


37  MEMORY  S^AN-SHORT  TERM  MEMORY 

38  MEMORY  SPAN- INTEGRATION  OF  INFORMAT I 

39  VISUAL  MEMORY 

40  EXPLOSIVE  STRENGTH-GENERAL 

41  EXPLOSIVE  STRENGTH-LEG  EMPHASIS 

42  EXPLOSIVE  STRENGTH-UPPER  BODY  EMPHAS 

43  STATIC  STRENGTH-ARM/HAND/SHOULDEh 

44  STATIC  STRENGTH-LEG/TRUNK 

45  DYNAMIC  STRENGTH-ARMS 

46  DYNAMIC  STRENGTH-LEGS 

47  TRUNK  STRENGTH 

48  EXTENT  FLEXIBILITY 

49  DYNAMIC  FLEXIBILITY 

50  GROSS  BODY  EQUILIBRIUM 

51  BALANCE-VISUAL  CUES 

52  GROUP  COOPERATION 

53  GROUP  COMMUNICATION 

54  LEADERSHIP 


HIT  'SPACE'  KEY  TO  CONTINUE 
ANY  OTHER  KEY  TO  EXIT  MENU 


55  GENERAL  COGNITIVE  ABILITIES 

56  GENERAL  PHYSICAL  ABILITIES 

ALL  SKILL  CATEGORIES  DISPLAYED 

ENTER  SKILL  CATEGORY  NUMBERS 
TO  BE  REVIEWED 

TYPE  'END* WHEN  LIST  IS  COMPLETE 

?  ce 

?29~ 

?END 

ARE  YOU  INTERESTED  ONLY  IN 
EXCLUSIVE  ARTICLES?  ( Y/N) Y 


ARE  YOU  INTERESTED  IN  THE  ARTICLES 
REFERENCING  THESE  SKILL  CATEGORIES? _Y 
ARTICLE  NUMBER  #TIMES  REFERENCED 


ARTICLE  NUMBER 


4TIMES  REFERENCED 


pr, 

v, 


j- 

i 


k\ 


90  -3 

92  6 

93  3 

101  1 

113  2 

116  4 

117  3 

121  1 

124  5 

133  6 

142  4 

143  3 

147  2 

148  1 

149  6 


MIT  ANY  KEY  TO  CONTINUE 


(SPACE  KEY) 

ARTICLE  NUMBER  4TIMES  REFERENCED 


152 

157 

161 

182 

109 

190 

196 


2 

2 

9 
1 
2 
3 

10 


TOTAL  NUMBER  OF  ARTICLE5-37 
TOTAL  NUMBER  OF  REFERENCES- 158 


ARE  YOU  INTERESTED  IN  THE  INDEPENDANT 
VARIABLES  WHICH  WERE  REFERENCED?  X- 
INDEPENDENT  VARIABLE  NAME  TIMES 


OPERATOR  TYPE 

GENERAL  PROFICIENCY  FACTOR 
»  THRESHOLD  CONTRAST 

.!  VISUAL  ACUITY 

;•*.*  GENERAL  APTITUDE  SCORE 

#  PRACTICE  TRIALS 
AMOUNT  OF  TRAINING 
PRESENCE  OF  FEEDBACK 

•  MASSED  VS  DISTRIBUTED  PRACTICE 

TYPE  OF  FEEDBACK 
TIME  OF  DAY 
1>  NOISE  LEVEL 

LIGHT  LEVEL 

I'.’  FLASH  INTENSITY 

*,  TIME  SPENT  ON  TASK 

HIT  ANY  KEY  TO  CONTINUE 
(SPACE  KEY) 


1 

1 

3 

2 

1 

2 

1 

1 

1 

1 

'2 

3 

1 

1 

2 
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INDEPENDENT  VARIABLE  NAME  TIMES 


DAYS  SPENT  ON  TASK 

SESSION  NUMBER (SHORT  SESSIONS) 

NUMBER  OF  POSSIBLE  RESPONSES 

MONOCULAR  VS  BINOCULAR  VIEWING 

SLEEP  DEPRIVATION 

NUMBER  OF  DISPLAYS  MONITORED 

SIGNAL  RATE 

PERCEIVED  PROBABILITY  OF  AN  EVENT 
TEAM  STRUCTURE 
NUMBER  OF  OBSERVERS 
TARGET  SIZE 

TARGET  BACKGROUND  TYPE 
BACKGROUND  LUMINANCE 
PERCENT  TARGETS  AMONG  SIGNALS 
TARGET  BRIGHTNESS 
HIT  ANY  KEY  TO  CONTINUE 


(SPACE  KEY) 


INDEPENDENT  VARIABLE  NAME  TIMES 


DISTANCE  TARGET  HAS  TRAVELED  1 

RELATIVE  DIRECTION  OF  TARGET  M0TI0N12 
TARGET  SPEED  2 

TARGET  TYPE  12 

CONTRAST  RATIO  (TARGET/BACKGROUND)  B 
TARGET  ANGLE  RELATIVE  TO  FOVEA  7 

NUMBER  OF  CUES  FOR  A  SIGNAL  2 

SEARCH  AREA  7 

TARGET  DISTANCE  16 

METEOROLOG I CAL  RANGE (VISIBILITY)  3 
TARGET  HORIZONTAL  DISTANCE  4 

VISUAL  AIDING  4 

TARGET  COLOR  4 

STIMULUS  MODE  2 

LENGTH  OF  EARLY  WARNING  1 

HIT  ANY  KEY  TO  CONTINUE 


(SPACE  KEY) 


INDEPENDENT  VARIABLE  NAME 


TIMES 


DISPLAY  RESOLUTION 


DISPLAY  CLUTTER 


NUMBER  OF  DISPLAY  COLORS 
SIGNAL  DURATION 


DIRECTION  OF  ILLUMINATION  SOURCE 
SCENE  COMPLEXITY 
TARGET  POSITION  ON  DISPLAY 
STEP  VS  RAMP  FAILURE 


1 

1 

1 

1 

l 

1 


DO  YOU  WISH  TO  REVIEW  THE  RESULTS?  _N 
1 


A 


V 


i 
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^-Example  of  IV  Ref  Count 


This  Is  an  example  of  the  execution  of  the  program  IV  REF  COUNT. 

It  prints  the  total  number  of  times  each  Independent  Variable  Is  referenced 
In  the  data  base. 


3 RUN  IV  REF  COUNT 


INDEPENDANT  VARIABLE  NAME  #TIMES 


RISK  ACCEPTANCE  0 

INTELLEGENCE  2 

AGE  O 

OPERATOR  TYPE  4 

SENSE  OF  DIRECTION  2 

WILLINGNESS  TO  TAKE  RISKS  1 

OBSERVATION  NOISE  4 

PERCEPTUAL  TIME  DELAY  3 

MOTOR  NOISE  3 

OPERATOR  GAIN  <8L9  COMBINED)  2 

GENERAL  PROFICIENCY  FACTOR  10 

THRESHOLD  CONTRAST  3 

ASPIRATION  LEVEL  b 

OPERATOR  PRECISION  1 

HIT  ANY  KEY  TO  CONTINUE 


(SPACE  KEY) 


r^iaurWM  ^^.s^TUPanurM^jna 


I 


INDEPENDANT  VARIABLE  NAME  #TIMES 


TEAM  SKILL  LEVEL  1 

!  TRACK I NS  ABILITIES  1 

|  MOTIVATION  LEVEL  1 

•  VISUAL  ACUITY  2 

J  GENERAL  APTITUDE  SCORE  1 

*  MORALE  LEVEL  1 

|  LEADERSHIP  ABILITY  i 


HIT  ANY  KEY  TO  CONTINUE 

(SPACE  KEY) 

INDEPENDANT  VARIABLE  NAME  #TIMES 


i 

* 

t 

f 

t 

4 

I 


#  PRACTICE  TRIALS  15 

TIME  SINCE  LAST  PRACTICED  5 

AMOUNT  OF  OVERLEARNING  .  1 

TIME  SINCE  INITIALLY  LEARNED  3 

TRAINING  EMPHASIS (SPEED  VS  COORD I NAT  2 
AMOUNT  OF  TRAINING  6 

PRESENCE  OF  FEEDBACK  3 

NUMBER  OF  CORRECT  CHOICES  1 

MASSED  VS  DISTRIBUTED  PRACTICE  1 

AMOUNT  OF  INITIAL  TRAINING  2 

TYPE  OF  FEEDBACK  1 

#  SUCCESSFUL  TRIALS 


i 

r 

t 

/ 

4 

4 


HIT  ANY  KEY  TO  CONTINUE 
(SPACE  KEY) 

independant "'Variable  name  #iimes 


AMBIENT  TEMPERATURE  2 

SKIN  TEMPERATURE  3 

TIME  OF  DAY  10 

NOISE  LEVEL  9 

LIGHT  LEVEL  5 

DISTANCE  BETWEEN  COMMUNICATORS  3 

TYPE  OF  NOISE  2 

WET  BULB  TEMPERATURE  1 

VIBRATION  LEVEL  1 

EFFECTIVE  TEMPERATURE  2 

GENERAL  STRESS  6 

FLASH  INTENSITY  1 


HIT  ANY  KEY  TO  CONTINUE 


(SPACE  KEY) 
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INDEPENDANT  VARIABLE  NAME  #TIMES 


INFORMATION  QUANTITY  (SAMPLE  SIZE)  1 
TIME  SPENT  ON  TASK  25 

ORGANIZATION  PERFORMING (SQUAD  1 

DAYS  SPENT  ON  TASK  9 

WORK/REST  CYCLE  9 

SESSION  NUMBER (SHORT  SESSIONS)  1 

NUMBER  OF  POSSIBLE  RESPONSES  16 

MONOCULAR  VS  BINOCULAR  VIEWING  1 

SLEEP  DEPRIVATION  18 

NUMBER  OF  TASKS  PERFORMED  AT  ONCE  S 
HOURS  WORKED  PER  WEEK  1 

IMPORTANCE  OF  TASK  PARAMETERS  4 

PHYSICAL  ENERGY  COST  OF  TASK  4 

NUMBER  OF  DISPLAYS  MONITORED  5 

HIT  ANY  KEY  TO  CONTINUE 


(SPACE  KEY) 


INDEPENDANT  VARIABLE  NAME  #TIMES 


SIGNAL  RATE  8 

DRUG  USAGE  1 

TIME  BETWEEN  STIMULUS  AND  RESPONSE  3 

PERCEIVED  PROBABILITY  OF  AN  EVENT  11 

PERCEIVED  COST  OF  ALTERNATE  DECISION  4 

PROBABILITY  OF  AN  EVENT  7 

MATERIAL  STRENGTH  RATIO-FRIEND/FOE  1 

PERSONNEL  STRENGTH  RATIO  FRIEND/FOE  1 

ENEMY  TERRAIN  ADVANTAGE  1 

UNIT  RESUPPLY  CONDITIONS  1 

TEAM  STRUCTURE  7 

NUMBER  OF  OBSERVERS  5 

OBSERVER  SCAN  PATTERNS  2 

SPEED  OF  TASK  STRESS  1 

BACKLOG  OF  WORK  2 

HIT  ANY  KEY  TO  CONTINUE 


(SPACE  KEY) 


t 

) 

i 

( 

/ 

/ 

i 


v 


5 
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INDEPENDANT  VARIABLE  NAME 


CONSISTENCY  OF  DATA 
OBSERVATION  TIME  PER  DISPLAY 
HISTORY  OF  SYSTEM  STATES 
URGENCY  OF  TASK 


HIT  ANY  KEY  TO  CONTINUE 


4TIMES 


1 

2 

1 

1 


INDEPENDANT  VARIABLE  NAME  #TIMES 


TARGET  SIZE  15 

TARGET  BACKGROUND  TYPE  -  13 

BACKGROUND  LUMINANCE  4 

PERCENT  TARGETS  AMONG  SIGNALS  2 

TARGET  BRIGHTNESS  6 

DISTANCE  TARGET  HAS  TRAVELED  1 

RELATIVE  DIRECTION  OF  TARGET  MOTION  26 
TARGET  SPEED  12 

TARGET  TYPE  24 

CONTRAST  RATIO  (TARGET/BACKGROUND)  16 
TARGET  ANGLE  RELATIVE  TO  FOVEA  12 

BLINDING  FLASH  ENERGY  3 

NUMBER  OF  CUES  FOR  A  SIGNAL  8 

COMMUNICATION  MODE  1 

HIT" ANY  KEY  TO  CONTINUE 


INDEPENDANT  VARIABLE  NAME  4TIMES 


CONTROL  SENSITIVITY 
CONTROL  DYNAMICS  (ORDER) 

TARGET  MOVEMENT  BANDWITH 
PROCESS  NOISE 
SEARCH  AREA 
TARGET  DISTANCE 

METEOROLOGICAL  RANGE (VISIBILITY) 

TARGET  HORIZONTAL  DISTANCE 

VISUAL  AIDING 

TARGET  COLOR 

STIMULUS  MODE 

RESPONSE  MODE 

LENGTH  OF  EARLY  WARNING 

DISPLAY  TYPE 

DISPLAY  RESOLUTION 

HIT  ANY  KEY  TO  CONTINUE 


1 

4 

7 

5 
12 

35 

7 

10 

7 

4 

5 
1 

2 

r> 
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INDEPENDANT  VARIABLE  NAME  #TIMES 


DISPLAY  CLUTTER  8 
NUMBER  OF  DISPLAY  COLORS  1 
MESSAGE  LENGTH  1 
MESSAGE  IMPORTANCE  1 
NUMBER  OF  SIGNAL/TARGET  DIMENSIONS  1 
SIGNAL  DURATION  2 
INTER  DISPLAY  ANGLE  1 
DIRECTION  OF  ILLUMINATION  SOURCE  1 
SCENE  COMPLEXITY  i 
TARGET  POSITION  ON  DISPLAY  1 
TASK  TYPE (PROCEDURAL  1 
SIGNAL  AMPLITUDE  3 
STEP  VS  RAMP  FAILURE  1 


HIT  ANY  KEY  TO  CONTINUE 
(SPACE  KEY) 


REPEAT?  <Y/N)N 
1 


L— 33 


Appendix  A 

PRINTOUT  OF 
ENTER  ARTICLES 
COMPUTER  PROGRAM 
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a ij  Wi.< 


r-f  r^^^.^nuryjiyjirjinx  ram*  rj> 


LOAD  ENTER  ARTICLES 
3LIST 

10  LP  -  IS 

20  DIN  NI (3) , ID* <3, 1000) . SK < 10) , 

TI (100) 

30  D*  -  CHR*  <4> 

42  PRINT  D*| "OPEN  SKILLS  X  IND  V 
ARS,D2M 

46  PRINT  D*j -APPEND  SKILLS  X  IND 
VARS" 

SO  PRINT  D*]"OPEN  SKILLS, Dl* 

70  PRINT  D*) "READ  SKILLS"!  INPUT 
SCl  DIN  ST* (SC) i  FOR  I  -  1  TO 
SCi  INPUT  ST* ( I ) i  NEXT  I 

72  PRINT  D»( "CLOSE  SKILLS" 

73  PRINT  D*] "OPEN  IND  VARS-10" 

75  FOR  I  -  1  TO  5 

SO  PRINT  D*; "READ  IND  VARS-10" 

90  INPUT  NI <I) 

100  PRINT  D*1 "OPEN  IND  VARS-"jI» 
PRINT  D*( "READ  IND  VARS-“;I 
«  FOR  J  -  1  TO  NI (I) t  INPUT 
ID*(I, J> 

103  NEXT  Ji  PRINT  D*; "CLOSE  IND 
VARS-"} I 
110  NEXT  I 
120  PRINT  D*i "" 

500  HOME  i  PRINT '"DO  YOU  WANT  TO 

ADD  A  NEW  ARTICLE  TO  " 1  PRINT 


"THE  DATA  BASE?  (Y/N) 

0* 

"i  GET 

510 

IF  LEFT*  (G* , 1 )  -  "Y 
1000 

"  GOTO 

512 

INPUT  "DO  YOU  WANT  TO 

QUIT? 

(Y/N) " ; 0*1  IF  LEFT* 

>  "Y”  GOTO  300 

(Q*,t> 

313 

PRINT  D*) "CLOSE" 

515 

END 

1000 

INPUT  “ENTER  ARTICLE 

NUMBER 

-",A;  PRINT  "ENTER  QUANTITAT 
IVENESS  INDEX  (0-3) -"|  SET  Q 


1003  IF  ASC  <0*>  ■  13  THEN  PRINT 
:  PRINT  "  ERROR"!  GOTO  1000 
1007  QU  -  VAL  (Q*  > 

1010  SN  -  O 

1100  PRINT  "DO  YOU  NEED  A,  SKILL 
CATEGORY  MENU?  (Y/N)"i  GET  Q 
*1  IF  Q*  <  >  "Y"  GOTO  1500 

11101-  INT  (SC  /  LP) i J  -  1 
1113  HOME  l  FOR  K  ■  (J  -  1)  *  LP 
♦  1  TO  J  I  LPi  PRINT  Ks"  "; 

LEFT*  (ST* (K) , 36) !  NEXT  K:  PRINT 

1120  PRINT  "HIT  ’SPACE’  KEY  TO  C 
ONTINUE"!  PRINT  "  ANY  OTHER 
KEY  TO  EXIT  MENU"!  GET  0*1  IF 
0*  <  >  "  "  THEN  PRINT  !  GOTO 

1500 

1123  IF  LEN  (0*>  <  I  GOTO  1500 
1130  IF  J  <  I  THEN  J  -  J  ♦  U  GOTO 
1113 

I  13(1  TP  T  t  !  P  a  P?  RHTn  1  ADO 


L-36 


1160  HOME  i  FOR  K  -  LP  *  I  *  1  TO 
SCl  PRINT  K;-  LEFT*  <ST*< 

K>  >  36) l  NEXT  K 

1400  INVERSE  I  PRINT  I  PRINT  "AL 
L  SKILL  CATEGORIES  DISPLAYED 
■«  NORMAL 

1500  PRINT  “ENTER  SKILL  CATEGORY 
NUMBER  OR" i  PRINT  “HIT  RETU 
RN  IF  ALL  SKILL  CATEGORIES"! 

INPUT  "HAVE  BEEN  ENTERED-"! 

0* 

1505  IF  0*  -  AND  SN  •  O  THEN 
INVERSE  l  PRINT  "NO  SKILL  C 
ATAGORIES  ENTERED  FOR")  PRINT 

"THIS  ARTICLI-START  AGAIN"!  NORMAL  l  GOTO  1100 
1310  IF  0*  •  ""  SOTO  1700 
1515  IF  VAL  <Q*)  <  1  OR  VAL  (0 
•>  >  SC  THEN  INVERSE  I  PRINT 
"VALUE  OUT  OF  RANGE-START  AO 
AIN"!  NORMAL  I  GOTO  HOO 
1520  SN  -  SN  ♦  liSK(SN)  m  VAL  (0 
•>l  HOME  !  PRINT  "ENTER  NEXT 
SKILL  CATE3QRY" i  GOTO  1100 
1700  IV  -  1 

1710  HOME  I  PRINT  "WHAT  TYPE  OF 

VARIABLE  IS  INDEPENDANT" i  PRINT 
"VARIAELE  NUMBER  "jIV 
1720  PRINT  i  PRINT  "  APTITUDE-I* 
t  PRINT  *  LEARN I NS/PRACT ICE“ 

2"!  PRINT  “  ENVIRONMENTAL-3" 

!  PRINT  '  T ASK  —PROCEDURE / STR 
ATEGY-4’ 

1730  PRINT  *  TASK-MAN/MACHINE  IN 
TERFACE-3"!  PRINT 
1740  PRINT  "HIT  ’RETURN’  IF  ALL 
VARIABLES  APE  IN" i  PRINT  "EN 
TER  ’9’  TO  SKIP  THIS  ARTICLE 

1900  GET  0*1  IF  ASC  (0*)  -  13  GOTO 

300 

1910  IN  -  VAL  (0*)|  IF  IN  »  9  GOTO 

500 

1920  IF  IN  >  0  AND  IN  <  6  GOTO  2 

000 

1930  INVERSE  I  PRINT  “OUT  OF  RAN 
GE-REENTER"!  NORMAL  i  GOTO  I 
720 

2000  N  -  LP 
2010  HOME 

2020  IF  N  <  NI ( IN)  THEN  FOR  I  » 

N  -  LP  *  I  TO  Nl  PRINT  It  TAB ( 

3) l I D* ( IN, 1 1 i  NEXT  Ii  PRINT 
"HIT  RETURN  FOR  MORE"!  GOTO 
2300 

2050  FOR  I  -  N  -  LP  ♦  I  TO  NI (IN 
) I  PRINT  Ij  TAB (  3)|ID*(IN,I 
>1  NEXT  I 

2090  INVERSE  !  PRINT  l  PRINT  ’AL 

L  VARIABLES  DISPLAYED"!  NORMAL 
!  PRINT 

2500  PRINT  "ENTER  VARIABLE  NUMBE 
R  IF  FOUND"!  PRINT  "ENTER  'A 
'  IF  NEW  VARIABLE  IS  REOUIRE 
D" 

2503  PRINT  “ENTER  ’M'  TO  RETURN 
.  Tn  VAR  TYPF  MFNI I" 
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PRINT  'ENTER  'R*  IF  MENU  MU 
8T  BE  REVIEWED' «  INPUT  Q* 

IF  0*  -  “M"  GOTO  1710 
IF  Qt  <  >  ““  GOTO  3000 

IF  N  >  -  NI(IN)  GOTO  2080 

N  ■  N  ♦  LPt  GOTO  2010 
IF  0*  <  >  'A'  GOTO  4000 

NI < IN)  -  NI(IN)  ♦  1«  PRINT  “ 
ENTER  NAME  OF  NEW  INDEPENDAN 
T  VAR  I ABLE* l  PRINT  "ENTER  '8 
PACE*  TO  RETURN  TC  MENU"!  INPUT 
ID*(IN.NI (IN) ) 

IF  LEFT*  (ID*(IN.NI (IN) )  ,  1 
)  -  '  "  OR  LEN  ( ID* ( IN, NI ( I 
*•»))  <  1  THEN  NI  ( IN)  -  NI  ( IN 
)  -  ll  GOTO  2010 
PRINT  D* J "OPEN  IND  VARS-"|I 
N|',D1" 

PRINT  D*| "POSITION  IND  VARS 
-'5 IN|",R";Nl (IN)  -  1 
PRINT  D* | " WR I TE  IND  VARS-“| 

INI  PRINT  ID* (IN,NI(IN>> 

PRINT  D*| "CLOSE  IND  VAR3-"> 

IN 

PRINT  D«l "CLOSE  IND  VARS-10 
"I  PRINT  D*J "OPEN  IND  VARS- l 
0' 

PRINT  D*l 'WRITE  IND  VARS-10 
"I  FOR  I  -  1  TO  Si  PRINT  NI ( 

I) I  NEXT  It  PRINT  D*| " “ 

10  -  NI ( IN) «  GOTO  4300 
IF  0*  -  "R"  GOTO  2010 
IF  VAL  (0*)  <  1  OR  VAL  <0 
*)  >  ni(in;  then  print  -inc 

CRPECT  ENTRV",  SOTO  2300 
10  -  VAL  <Q*> 

FOR  I  •  I  TO  SMI  PRINT  I  PRINT 
*SKILL»"»SK(I>»"  ‘J'lNDVAR- 
"lIOl'  ARTICLE”" I  At  NEXT  I 
PRINT  'ALL  INFORMATION  CORR 
CCT-’  IV/N)'I  GET  0«t  IF  LEFT* 
(0*,1>  <  5  "V"  GOTO  2300 

PR INT  D*l ‘APPEND  SKILLS  X  I 
ND  VARS" 

FOR  I  ■  1  TO  SN 
PRINT  D*» 'WRITE  SKILLS  X  IN 
D  VAR3 " 

PRINT  SKI  I)  I"  “  |  IN|  "  "|I0|“ 

" I A| "  "|0U|"  "(SN 
NEXT  I 
PRINT  D*l  “' 

IV  -  IV  *  li  OPT)  1710 
END 


JLQAD  DATA  BASE  ANALYSIS 
3LI8T 


3  HOME 
lO  LA  -  10 

20  DIN  NI (3) , ID* <3, lOOO) , SK < 10) , 
TI <100) ,SR(60) ,NA(3,130> ,AR< 
300) 


30  D«  •  CHAO  14) 

SO  RRINT  D*|"OPEN  SKILLS, Dl" 

70  PRINT  D*| "READ  SKILLS"!  INPUT 
SCt  DIM  3T*(SC)i  FOP  I  -  1  TO 
SCi  INPUT  ST*  (Dl  NEXT  I 

72  PRINT  D*» "CLOSE  SKILLS" 

73  PRINT  D*j "OPEN  IND  VAPS-10" 

73  FOR  I  -  1  TO  3 

BO  PRINT  D*{ "READ  IND  VARS-10" 

RO  INPUT  NI (I) 

100  PRINT  D*» "OPEN  IND  VAR3-"|Il 
PRINT  D* I "READ  IND  VARS-" i I 
I  FOR  J  -  1  TO  Nil  I) I  INPUT 
ID*  <  I ,  J  > 

103  NEXT  Jt  PRINT  D«| "CLOSE  IND 
VARS-" 1  I 
110  NEXT  I 
120  PRINT  D*l "“ 

llOO  PRINT  "DO  YOU  NEED  A  SKILL 
CATEGORY  MENUT  ( Y/N; " ■  GET  Q 
*«  IF  C»  <  >  "Y"  BCTO  1300 

1110  I  -  INT  <  EC  /  LP>  s J  -  1 
1113  HOME  s  FCFi  K  -  (J  -  1)  *  LP 


♦  1  TO  J  *  LP.  PRINT  K»"  " 
LEFT*  t ST  *  (K )  , 36) t  NEXT  Ki 


1 


PR  IN' 


1120  PRINT  "HIT  'SPACE'  KEY  TO  C 
ONTINUE"!  PRINT  »  ANY  OTHER 
KEY  TO  EXIT  MENU" I  GET  0*1  IF 
0*  <  >  *  "  THEN  PRINT  i  GOTO 

1300 

1123  IF  LEN  (0*)  <  1  GOTO  1300 

1120  IF  J  <  I  THEN  J  •  J  ♦  ll  GOTO 
1113 

1130  IP  I  *  LP  -  SC  GOTO  1400 

1160  HOME  I  FOR  K  •  LP  *  I  *  1  TO 
SCi  PRINT  f.|"  "I  LEFT*  (ST*< 

K) ,36>l  NEXT  K 

1400  INVERSE  «  PRINT  i  PRINT  "AL 
L  SKILL  CATEGORIES  DISPLAYED 
'I  NORMAL 

1300  PRINT  «  PRINT  'ENTER  SKILL 
CATEGORY  NUMBERS”!  PRINT  "TO 
BE  P£ VIEWED " 

1310  PRINT  -TVPE  'END' WHEN  LIST 
IS  COMPLETE". NS  •  O 

1320  INPUT  0*.  IF  LEFT*  I0*,1)  - 
-£■  GOTO  2000 

1330  IF  VAL  (0*>  *■  I  OR  VAL  0 
*1  '  SC  then  PRINT  x  PRINT 

'CUT  OF  RANGE -REENTER"!  G0T0 
1320 

1340  SR'  VAL  <D*;i  »  SiNS  *  NS  * 
ll  GOTO  1320 


rx av»%  v-.  x>: 


2000  PRINT  D*| "OPEN  SKILLS  X  INO 
VARS-H0D.D2" 

2010  PRINT  "ARE  YOU  INTERESTED  0 
NLW  IN  *»  INPUT  "EXCLUSIVE  A 
RTICLES?  <Y/N>"»Q*i  IF  LEFT* 
<0*,1)  -  "Y"  THEN  EX  ■  1 

2100  PRINT  D*| “READ  SKILLS  X  INB 
VARS-HOD" 

2200  ONERR  SOTO  3000 

2300  FOR  K  -  1  TO  6i  INPUT  X (K) I 
NEXT  K 

2310  IF  SR  <  X ( 1 >  >  <  1  SOTO  2300 

2320  IF  EX  -  1  AND  X (6)  >1  SOTO 
2300 

2330  AR(X(4>)  ■  AR (X  (4) >  ♦  1|NA(X 
<2) >  X (3) >  -  NA(X (2) >  X (3) )  ♦ 
tl  SOTO  2300 

3000  IF  PEEK  (222)  <  >5  THEN 

PRINT  *«**  ERROR  •  ***!  END 

3010  POKE  216.01  PRINT  i  PRINT  * 
ARE  YOU  INTERESTED  IN  THE  AR 
TICLE3  *t  INPUT  ‘REFERENCING 
THESE  SKILL  CATEGORIES?  "«0 
•  t  IF  LEFT*  (Q*,l>  “  "N"  SOTO 
4000 

3020  I  »  liTA  -  OiTR  -  O 

3030  PL  -  ll  HOWE  I  PRINT  "ART I CL 
E  NUHBER  •TIWES  REFERENC 

•  ED" 1  PRINT  * - 

- PRINT 

3040  IF  ARID  >0  THEN  PRINT  !| 
TAB (  21 ) J AR(I <  tPL  •  PL  *  ll 
TA  -  TA  ♦  HTR  -  TR  *  ARM) 

3030  I  -  I  ■*  1 1  IF  I  >  300  GOTO  4 
000 

3060  IF  PL  >  IS  THEN  PRINT  "HIT 
ANY  KEY  TO  CONTINUE “I  BET  0 
*:  DC Tu  3030 

3070  SOTO  3040 

4000  PRINT  I  PRINT  'TOTAL  NUHBER 
OF  ART!ClE5»"»TA«  PRINT  "TO 
TAL  NUHBER  OP  REFER*NCE5-”TR 


4003  PRINT  I  PRINT  "ARE  YOU  INTE 

RESTED  IN  THE  JNDEPENDANT- i  INPUT 
•VARIABLES  WHICH  WERE  REFERE 
NCED'*  --.0*1  IF  LEFT*  (0*,1> 

-  “N"  SOTO  3000  | j 

4010  I  »  IlJ  •  1 

4020  PL  •  l>  HOME  I  PRINT  "INDEPE 
NDENT  VARIABLE  NAHE 
TINES"!  PRINT  ‘ - 


4030  IF  NAU.J)  >  O  THEN  print 
left*  (!D*<t.J). 33 >  t  7AB(  3 
6) «NA( I, J) iPL  •  PL  ♦  I 
4033  J  •  J  *  1 

4040  IF  J  >  Pi  I  C  X  >  THEN  J  «  III  « 
1  •  ll  IF  I  >  3  GOTO  5000 
4060  IF  PL  '  IS  THEN  PRINT  'HIT 
ANY  KEY  TO  CONTINUE"!  SET  0 
•l  GOTO  4020 
Ari-rn  nnrn  4 /vr* 


5000  PRINT  I  INPUT  *00  YOU  WISH 
TO  REVIEW  THE  RESULTS'*  *|0*l 
IF  LEFT*  <Q*,1)  -  "V"  GOTO 
3000 
5010  END 


Appendix  C 

PRINTOUT  OF 
IV  REF  COUNT 
COMPUTER  PROGRAM 


LOAD  IV  REF  COUNT 
3LIST 


S  HOME 
B  B*  -  "  " 

10  LP  -  IS 

20  DIM  NI <3> . IDV<3, 1000) ,SK<10) , 
TI < 100) ,SR(60) ,NA<5, 130) ,AR< 
300) 

30  D*  -  CHR*  (4) 


73 

PRINT 

« 

D*| “OPEN 

IND 

VARS-10,01 

73 

FOR  I 

-  1  TO  3 

80 

PRINT 

D*| “READ 

IND 

VARS- 10“ 

90 

INPUT 

NI  ( I  > 

too 

PRINT  D*: "OPEN 

IND  VARS-”; I : 

PRINT  C*»“READ  IND  VARS-”: I 
5  FOR  J  ■  1  TO  NIIDi  INPUT 


ID* (Ia J) 

103  NEXT  Ji  PRINT  D*| “CLOSE  iND 
VAR9-" | I 
110  NEXT  I 
120  PRINT  D*l " “ 

200  PRINT  D*j "OPEN  SKILLS  X  IND 
VARS— MOD, D2" i  PRINT  D»! "READ 
SKILLS  X  IND  VARS-MOD" 

220  ONERR  GOTO  500 
230  INPUT  A.B,C,D,E,F 
240  NA <B, C>  -  NA(B,C)  ♦  Is  GOTO  2 
30 

300  IF  PEEK  (222)  <  >3  THEN  STOP 

510  POKE  216,0 
550  FOR  I  -  1  TO  3 
335  PL  -  Os  PRINT  i  HOME  s  PRINT 
" INDEPENDANT  VARIABLE  NAME 

•TIMES”:  PRINT  ” - 


560  FOR  J  -  1  TO  NI ( I) 

362  PL  -  PL  *  1 

370  IF  PL  -  15  THEN  PRINT  “HIT 
ANY  KEY  TO  CONTINUE":  GET  Q» 

:  HOME  :  PRINT  "INDEPENDANT 
VARIABLE  NAME  #TIMES 

”1  PRINT  " - 

-  - “,PL  - 

0 

580  PRINT  LEFT*  ( I D* ( I , J > , 36) |  TAB  < 
3S ) ; NA ( I , J ) 

590  NEXT  J 

593  PRINT  t  PRINT  "HIT  ANY  KEY  T 
0  CONTINUE":  GET  0* 

600  NEXT  I 

610  INPUT  “REPEAT-’  (Y/N)“:0»:  IF 
Q*  <  I  ”N“  GOTO  530 
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SECTION  IV  TECHNICAL  DISCUSSION 

r" 

This  report  presents  a  model  of  the  human  that  will  be  used  in 
MOPADS.  This  model  is  distinct  from,  the  quantitative  models  which  will 
be  used  to  predict  human  performance  times .  The  quantitative  models 
are  not  aimed  at  treating  the  human  holistically;  rather,  they  treat 
the  human  as  a  performer,  of  particular  tasks  such  as  identification, 
tracking,  and  so  on.  The  model  presented  herein  is  a  formal  model  of 
the  underlying  human.  The  reason  for  creating  such  a  formal  human 
model  is  first,  to  provide  a  holistic  framework  within  which  the 
overall  operator  models  can  be  described  and  discussed,  and  second, 
to  serve  as  a  cross-check  on  the  quantitative  models.  The  method 
of  cross-checking  will  be  presented  later  in  this  report. 

The  development,  of  this  "underlying,  person-model”  began  with 
a  review  of  the  air  defense  scenario,  to  be  modeled.  We  determined 
that  the  following  pieces  of  air  defense -equipment  vould.be  used; 
Missile  Minder  (AN/TSQ-73),  HAWK  missile.  Redeye  missile.  Chaparral 
missile,  and  Vulcan  gun.  The  scenario  involves  the  loading,  aiming, 
firing,  and  other  uses  of  these  weapons  and  devices,  but  not  setup, 
teardovn,  or  movement  of  the  weapons.  Given  this  context,  we  iden¬ 
tified  six  overall  tasks  to  be  performed  at  various  positions  in  the 
air  defense  network.  These  are:  tracking  of  targets  on  a  CRT, 
assignment  of  targets  using  automated  or  semiautomat  ed  equipment, 
communication  via  voice  or  teletype,  command  decision  making  and 
team  coordination,  ammunition  preparation  and  loading,  and  gunnery 
involving  optical  tracking  and  physical  guidance  of  the  weapon 
system. 


Proceeding  from  this  knowledge  of  tasks  to  be  performed,  we 
constructed  a  model  of  the  human  operator.  Systems  used  extensively 
in  air  defense  tasks  are  given  greater  emphasis  and  definition  in  f 

relation  to  the  less  important  body  parts  and  activities.  For  J 

example,  our  person-model  has  no  digestive  system,  but  has  a  huge  ' 

finder  dexterity  system.  i 


This  model  will  enable  the  modelers  to  focus  on  those  aspects 
of  the  human  which  are  most  important.  It  will  be  used  in  part  to 
decide  which  skills  are  involved  in  any  given  air  defense  task.  It 
will  also  be  used  as  a  check  on  the  completeness  of  the  skill  mod¬ 
erator  functions,  to  ensure  that  all  moderating  functions  have  been 
fully  specified,  that  is  that  all  important  variables  have  been 
included.  A  moderating  function  is  specified  in  terms  of  terms  of 
individual,  environmental,  and  human -machine  system  variables  that 
will  affect  performance  of  any  skill  from  the  skills  taxonomy,  a 
copy  of  which  is  presented  in  Table  1-1. 
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Table  1-1 .  Skills  Taxonomy 


/ 


GENERAL  BEHAVIORS 
VIGILANCE 

PROBABILITY  ESTIMATION 
TIME  ESTIMATION 
HOMAN  RELIABILITY  ASSESSMENT 
MEANINGFUL  MEMORY  ABILITY 
VERBAL  KNOWLEDGE 
WORD  FLUENCY 
NUMERICAL  ABILITY 
CONCEPT  FLUENCY 
DISCOVERY  OF  PRINCIPLES 
FLEXIBILITY 
,  SYMBOL  MANIPULATION 
DECISION  MAKING 
INTELLEGENCE 

FINE  MANIPULATIVE  ABILITIES 
POSITION  ESTIMATION 
GROSS  MANIPULATIVE  ABILITIES 
CONTROL  PRECISION 

SPEED  OF  ARM  MOVEMENT  I 

,  MULT I LIMB  COORDINATION 
POSITION  REPRODUCTION 
I  MOVEMENT  ANALYSIS 

I  MOVEMENT  PREDICTION 

ACCELERATION  CONTROL 
REACTION  TlhE 
TRACKING 
DETECTION 

DISCRIMINATION  ABILITIES  f 

TIME  SHARING 

CLOSURE  AE|  I L I T  2  ES  ( PERCEPTUAL ) 

AUDITORY  ABILITIES 
SPATIAL  ABILITIES-ORIENTATION 
SPATIAL  ABILITIES— VI SUALI ZATIDN 
•  ASSOCIATE  MEMORY-RCJTE  MEMORY 
ASSOCIATE  MEMORY-MEANINGFUL  MEMORY 
MEMORY  SFAN-SHORT  TERM  MEMORY 
MEMORY  SPAN- INTEGRATION  OF  INFORMATION 
VISUAL  MEMORY 

EXPLOSIVE  STRENGTH-GENERAL 


) 
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Tatie  1-1  ( continued) 


EXPLOSIVE  STRENGTH-LEG  EMPHASIS 

EXPLOSIVE  STRENGTH -UPPER  BODY  EMPHASIS 

STATIC  STRENGTH— ARM/HAND/ SHOULDER 

STATIC  STRENGTH-LEG/TRUNK 

DYNAMIC  STRENGTH-ARMS 

DYNAMIC  STRENGTH-LEGS 

TRUNK  STRENGTH 

EXTENT  FLEXIBILITY 

DYNAMIC  FLEXIBILITY 

GROSS  BODY  EQUILIBRIUM 

BALANCE- VISUAL  CUES 

GROUP  COOPERATION 

GROUP  COMMUNICATION 

LEADERSHIP 

GENERAL  COGNITIVE  ABILITIES 
GENERAL  PHYSICAL  ABILITIES 


The  person-axlel  itself  is  &  collection  of  human  systems  and 
activities.  One  constraint,  stated  above,  is  that  they  be  relevant 
to  the  air  defease  scenario.  Activities  vhich  are  not  relevant  are 
not  part  of  the  model.  Another  constraint  on  these  activities  is 
that  they  can  he  viewed  as  bodily  systems. 

The  nodel  divides  the  human  into  five  systems:  l)  perceptual, 
2)  information  processing,  3)  information  storage,  1»)  motor,  and 
5)  affective.  In  accordance  with  the  above  description  of  the 
model's  purpose,  these  five  systems  represent  areas  of  importance 
to  the  air  defense  modeling  goal.  It  would  have  been  possible  to 
compress  or  expand  this  list,  but  it  was  felt  that  these  represent 
equivalent  levels  of  description.  Each  of  the  systems  is  then 
subdivided  into  one  or  more  activities. 

The  model  can  he  understood  best  by  reviewing  these  systems 
and  activities ,  along  with  a  definition  of  each  activity.  The 
reader  who  wishes  to  understand  this  model  is  urged  to  build  a 
mental  picture  of  a  human  which  has  only  these  activities  as  its 
attributes.  Table  1-2  presents  an  overview  of  tbc  activity  listing. 

Figure  1-1  presents  a  matrix  of  the  interrelationships 
between  the  skills  in  the  taxonomy  and  the  subsystems  of  the 
person-model.  Those  cells  of  the  matrix  which  are  marked  by  an 
"X"  indicate  that  the  subsystem  (identified  by  the  column  title) 
plays  a  significant  part  in  the  performance  of  the  skill  (identi¬ 
fied  by  the  row  title).  This  matrix  vas  prepared  based  upon  an 
intuitive  examination  by  the  authors. 

The  next  step  in  the  use  of  this  person-model  behind  MOPADS, 
will  be  as  a  cross-check  on  the  completeness  of  the  moderator 
functions.  Once  the  candidate  set  of  independent  variabJ.es  that 
will  mediate  human  performance  is  prepared,  (to  be  summarized  in 
Laughery  (1963))  another  matrix  will  be  developed.  This  matrix 
will  be  similar  to  that  presented  in  Figure  1-2.  The  cells  in  thf.i 
matrix  marked  with  an  "X"  represent  e.  subsystem  which  is  affected 
in  some  manner  by  an  independent  variable.  .  This  matrix  will  also 
be  developed  on  the  basis  of  intuitive  Judgements  by  the  authors. 
Since  it  is  intended  to  be  only  a  cross-check  on  the  completeness  < 
the  moderator  functions,  a  full-scale  research  effort  on  the  develi 
ment  of  this  matrix  is  unnecessary.  Finally,  simple  matrix  algebr* 
will  be  performed  on  the  matrices  in  Figures  1-1  and  1-2  to  deter¬ 
mine  which  independent  variables  should  be  included  to  moderate 
each  skill  in  the  taxonomy.  These  results  will  then  be  compared  tt 
the  moderator  functions  being  developed  to  determine  whether  they 
include  all  of  the  independent  variables  suggested  by  this  analysi; 
At  this  point,  suggestions  for  further  literature  review  and 
research  where  required  will  be  amended  to  this  report. 


any  physical  source.  Input  sources  may  be  body  damage 
or  fatigue. 
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MEMORY  SPAN- INTEGRATION  OF  INFORMAT I 
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I.  PURPOSE 


The  purpose  of  this  report  is  to  document  the  thinking 
and  procedures  behind  the  development  of  the  skill  moderator 
functions  described  in  MOPADS  Report  5.10.  In  report  5.10., 
a  series  of  computer  subroutines  are  defined  which  will 
facilitate  more  realistic  modeling  of  human  operator 
performance.  Herein,  we  will  discuss  the  logic  behind  this 
approach  and  the  steps  taken  to  develop  the  subroutines 
presented  in  MOPADS  Report  5.10. 

The  remainder  of  this  section  will  present  some 
background  information  f"r  individuals  with  a  limited 
understanding  of  human  operator  modeling  via  network 
simulation.  Section  II  will  discuss  the  logic  behind  the 
development  of  these  subroutines  as  *ell  as  presenting  a 
brief  description  of  how  they  would  be  incorporated  into  a 
simulation  (a  more  detailed  discussion  of  specific  steps  s 
presented  in  MOPADS  Report  5.6).  Section  III  will  discuss 
the  steps  which  were  followed  in  the  development  of  these 
skill  moderator  function  subroutines.  Finally,  Section  IV 
will  briefly  define  some  advantages  and  disadvantages  of  this 
approach. 

1-1  Background 

Simulation  modeling  is  a  powerful  analytic  tool  whose 
potential  is  just  being  recognized.  Low  cost  computational 
capabilities  and  readily  available  simulation  languages  are 
sure  to  result  in  a  rise  in  the  use  of  simulation  to  answer 
questions  which  would  otherwise  go  unanswered. 

Additionally,  simulation  modeling  is  being  applied  to 
new  problem  areas.  One  of  the  more  promising  applications  of 
simulation  is  in  modeling  and  evaluating  human  operator 
performance.  In  the  past,  the  primary  means  for  evaluating 
human  performance  was  empirical  data  collection.  For  systems 
or  situations  which  did  not  yet  exist,  the  only  recourse 
available  to  the  analyst  was  to  look  for  existing  analogous 
situations.  Then,  the  analyst  could  draw  inferences  about 
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how  the  human  would  perform  in  the  new  situation  by 
estimating  the  differences  between  the  new  and  the  old 
situation.  In  many  cases,  reasonably  analogous  situations 
did  not  ax i s t .  Even  when  they  did  exist,  the  process  of 
extrapolating  to  the  new  situation  was  largely  based  on 
intuition.  The  result  was  a  poor,  if  any,  estimate  of  human 
performance. 

Now,  simulation  tools  exist  which  are  specifically 
designed  for  modeling  the  human  operator  of  a  system.  The 
analyst  interested  in  evaluating  human  performance  can  use 
these  tools  to  construct  a  computer  model  of  the  human  in 
much  the  same  way  that  a  bridge  designer  can  build  a  computer 
model  of  a  bridge.  Then,  the  computer  model  can  be  used  to 
test  various  concepts  of  human  operator/system  design  in  a 
reasonable  manner  long  before  the  system  t>r  situation 
actually  exists . I  , Additionally,  exercising  computer  models  is 
far  less  costly  than  experimentation  with, human  subjects. 
Therefore,  more  alternatives  can  be  considered  within  the 
same  amount  of  time  and  resource  expenditures. 

Over  the  past  few  years,  techniques  for  better 
simulation  of  humans  within  systems  have  become  available 
(e.g.,  Wortman,  Duket,  Hann,  Chubb,  and  Seifert;  1976,  Streib 
and  Wherry,  1979).  One  of  the  most  notable  approaches  is 
task  network  simulation  as  used  by  the  SAINT  (Systems 
Analysis  of  Integrated  Networks  of  Tasks)  simulation 
language.  With  SAINT,  human  performance  is  separated  into  a 
network  of  tasks.  Each  node  of  the  network  represents  a 
discrete  task  performed  by  the  human.  The  human  only 
performs  one  task  at  a  time.  The  network  structure  of  the 
tasks  defines  ordering  relationships  representing  how  the 
human  performs  the  tasks.  Therefore,  the  task  that  the  human 
is  performing  during  the  simulation  is  represented  by  the 
node  in  the  network  currently  being  executed.  Associated 
with  each  node  are  the  following  attributes: 


1.  Time  to  complete  the  task. 
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2.  If  the  task  is  always  followed  by  the  same  task, 
the  task  to  be  performed  after  the  current  task 
is  complete. 

3.  If  the  task  can  be  followed  by  several  tasks,  the 
list  of  possible  tasks  to  be  performed  after  the 
current  task  is  complete  as  well  as  decision  rules 
for  selecting  among  each  of  the  possible  next 
tasks . 

4.  Any  user  code  to  modify  simulation  variables  when 
the  task  is  performed,  if  performance  of  the  task 
affects  any  of  these  variables. 

5.  Task  number  (arbitrarily  assigned). 

6.  Task  name. 

Once  these  attributes  are  determined  for  each  subtask,  a 
computer  model  of  the  task  network  can  be  readily  developed 
via  the  SAINT  modeling  language.  Once  the  model  is 
computerized,  simulation  experiments  can  be  conducted  by 
varying  the  subtask  attributes.  For  example,  if  we  want  to 
explore  the  overall  effect  of  the  slower  performance  of  some 
of  the  subtasks,  we  would  simply  change  the  "time  to  perform" 
attribute  of  those  subtasks  and  then  run  the  simulation 
model.  Since  performance  times  are  probabilistic  (i.e.,  they 
are  randomly  sampled  from  a  known  distribution),  we  can 
obtain  estimates  of  the  probability  distribution 
representing  time  to  perform  the  overall  task  network. 

To  provide  an  example  of  a  SAINT  network,  let  us  use  an 
example  of  a  human  fishing.  Figure  1-1  presents  a  visual 
depiction  of  our  proposed  network  of  a  human  fishing.  As  one 
follows  through  the  network,  you  can  see  the  human  cast,  wait 
for  a  nibble,  attempt  to  catch  a  fish  if  a  nibble  occurs,  or 
reel  in  the  line  after  a  period  of  time  if  no  nibble  occurs. 
If,  for  example,  we  wanted  to  explore  the  effect  on  the  time 
required  to  catch  a  fish  of  reeling  in  the  line  more 
frequently  to  check  the  bait,  we  would  simply  change  the 
attribute  of  task  number  4  from  120  seconds  to  whatever 
number  is  desired.  This,  of  course,  would  confound  with  the 
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Figure  1-1 

SAINT  NETWORK  FOR  A  HUMAN  FISHING 


probability  of  a  nibble  occurring  in  task  3.  A  parametric 
experiment  testing  the  effects  of  these  two  variables  could 
easily  be  conducted  using  SAINT.  This  example  is  intended  to 
provide  the  reader  with  an  example  of  SAINT  modeling  using  a 
familiar  task.  Far  more  practical  applications  have  been 
found  tor  SAINT  including  visual  search  (e.g.,  Kraiss  and 
Kr.atuper,  1982)  and  aircraft  piloting  (e.g.,  Maralidharan , 
Baron,  and  Feehrer,  1979).  It  is  safe  to  say  that  SAINT  has 
become  the  de  facto  standard  language  in  task  network 
modeling  of  human  performance. 

The  remainder  of  this  report  discusses  an  approach  to 
improving  the  predictive  ability  of  SAINT  or  other  task 
network  models  of  human  operator  performance. 
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II.  THE  LOGIC  AND  CONCEPTS  BEHIND 
THE  MODERATOR  FUNCTION  APPROACH  TO 
INCLUDING  HUMAN  VARIABILITY  IN  SAINT  MODELS 


In  most  previous  applications  of  SAINT,  the  time 
required  by  the  human  to  perform  any  task  in  a  network  was 
defined  by  a  probability  distribution  type  and  the  associated 
distribution  parameters  (e.g.,  normal  distribution  with  a 
mean  of  4  seconds  and  a  standard  deviation  ef  1  second).  No 
attention  was  given  to  the  fact  that  human  performance 
variability  is  not  truly  random  but,  rather,  somewhat 
predictable.  In  other  words,  when  a  human's  performance 
speeds  up  or  slows  down  significantly,  it  is  not  usually 
because  of  random  variation  but  because  of  causal  factors 
such  as  heat  stress,  training  level,  and/or  a  host  of  other 
ability,  environmental,  or  task  variables  which  could  affect 
the  human's  performance.  We  know  that  these  variables 
influence  human  performance  but  how  can  we  quantify  these 
relationships  in  a  manner  that  can  be  used  by  task  network 
models? 

What  was  needed  to  include  the  effects  of  "human 
factors"  into  SAINT  model?  were  mathematical  functions  which 
relate  changes  in  human  performance  to  the  values  of 
independent  variables  of  interest  (e.g.,  ambient  temperature, 
drug  use,  etc.).  Moreover,  we  can  assume  that  these  changes 
in  performance  will  not  be  constant  among  all  tasks  in  a  task 
network.  For  example,  the  use  of  some  drugs  may  affect 
cognitive  performance  but  not  motor  performance. 

Consequently,  those  tasks  in  the  network  involving  cognitive 
behavior  would  be  affected  and  those  tasks  involving  motor 
beha/ior  would  not  be  affected.  In  essence,  a  unique 
mathematical  relationship  linking  human  performance  to  the 
values  of  human  factors  independent  variables  needed  to  be 
developed  for  every  task  in  a  network.  Stated  mathematically 
for  every  task  in  the  task  network  v’e  need  the  following: 


Change  in 

time  to  »  f .  (x. ,  x5,  x~,  .  ...x  ) 

perform  task  i  *  A  ^  ' 

in  the  network 


where 

f,*  the  function  relating  changes  in 
performance  of  task  i  to  the 
independent  variables  known  to 
affect  performance  of  task  i 

x.“  value  of  independent  variable  j 
which  affects  the  performance  of 
task  i 

n  ■  the  number  of  independent  variables 

which  affect  the  performance  of  task  i 


Even  in  a  relatively  small  task  network  of  100  tasks, 
this  would  entail  the  development  of  100  functions  to 
"moderate”  task  performance.  What  was  needed,  and  has  been 
developed,  is  a  method  of  building  these  moderator  functions 
in  a  logical  and  timely  manner. 

On  the  other  hand,  one  general  moderator  function  could 
be  developed  for  ail  tasks.  The  problem  with  using  the  same 
moderator  function  for  each  task  in  a  network  is  that  human, 
factors  variables  will  affect  different  skills  in  different 
manners.  As  was  mentioned  previously,  some  variables  will 
affect  cognitive  skills  only,  some  will  affect  only  motor 
skills,  and  some  will  effect  both.  Even  a  variable  which 
affects  cognitive  skills  only  may  not  affect  all  kinds  of 
cognitive  skills.  For  example,  fine-motor  skills  may  be 
affected  by  cold  stress  whereas  numeric  manipulation  skills 
may  not  be.  However,  there  may  be  a  level  of  skill  breakdown 
where  all  tasks  involving  a  certain  skill  type  will  be 
similarly  affected  by  human  factors  variables.  In  other 
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words,  we  may  I  be  able  to  define  a  finite  set  of  skill 
categories  so  that  all  tasks  requiring  a  particular  skill  is 
affected  by  the  human  factors  variables  in  approximately  the 
same  way. 

For  example,  if  one  of  the  skill  categories  is  "fine 
motor  manipulation",  then  all  tasks  which  involve  the  skill 
of  fine  motor  manipulation  will  be  affected  by  human  factors 
variables  in  the  same  way.  Then,  we  should  be  able  to 
develop  a  moderator  function  for  tasks  requiring  fine  motor 
manipulation  \ltfhich  relates  task  performance  changes  to 
independent  variables  known  to  affect  fine  motor  manipula¬ 
tion.  For  example,  let  us  assume  that  we  know  the 
relationship  between  fine  motor  mar.ioulation  and  the  variable 
"hours  since  last  sleep  was  received^'  to  be  the  following: 

Change  in  time  t 
perform  a  task 
involving  finO 
motor  manipulation 
skills 

(if  hours  since  last  sleep  >10.0) 
or 

=>  0 

(if  hours  since  last  sleep  <10.0) 


This  says  that  for  any  task  involving  fine  motor  manipula¬ 
tion,  we  can  expect  a  5.0%  increase  in  time  to  perform  the 
task  for  every  hour  beyond  10.0  hours  since  the  operator  last 
slept.  Note  that  this  function  would  only  apply  to  tasks 
involving  fine  motor  manipulation.  Other  skills  might  have 
other  functions  relating  skill  performance  changes  to  sleep 
deprivation.  Addi  t-ionally ,  fine  motor  manipulation  might  be 
affected  by  a  host  of  other  independent  variables  such  as 
ambient  temperature,  hours  of  sleep  received,  etc. 


Mean  time  (hours  since 

-  to  perform  X  last  sleep)  -  10 

the  task  - 

20.0 
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We  took  the  aforementioned  approach  for  the  MOPADS 
effort.  Obviously,  in  selecting  this  approach,  two  major 
hurdles  had  to  be  overcome.  First,  what  was  the  set  of 
skills  which  could  be  used  to  describe  all  operator  task 
types?  Second,  for  each  skill,  w^at  human  factors  variables 
affected  skill  performance  and  what  was  the  quantitative  link 
(e.g.,  moderator  function)  between  skill  performance  and 
these  independent  variables? 

Two  years  were  spent  answering  the  above  questions.  The 
skill  categories  were  selected  by  reviewing  numerous 
categorization  schemes  of  human  performance.  We  were  looking 
for  the  right  balance  of  detail  and,  yet,  not  so  many 
categories  that  it  would  be  difficult  to  decide  which  skill 
correctly  describes  a  task.  The  categories  which  were 
finally  selected  are  presented  in  Table  1. 


Table  1 

SKILL  CATEGORIES 


1.  Detection 

2.  Fine  Manipulative  Ability 

3.  General  Physical  Effort 

4.  Gross  Manipulative  Ability 

5.  Long-term  Memory/Sensory 

6.  Long-term  Memory/Symbolic 

7.  Numeric  Manipulation 

8.  Probability  Estimation 

9.  Reaction  Time 

10.  Recognition 

11.  Short-term  Memory/Sensory 

12.  Short-term  Memory/Symbolic 

13.  Team  Coordination 

14.  Time  Estimation 

15.  Timesharing 

16.  Tracking 
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Then,  wa  had  to  quantitatively  link  performance  of  a 
task  requiring  that  skill  to  variables  known  to  affect  that 
skill.  This  required  two  steps.  First,  we  had  to  determine 
which  human  factors  variables  affected  each  skill.  Second, 
we  had  to  mathematically  define  how  the  variables  affected 
the  skills.  Obviously,  we  did  not  want  to  develop  "armchair" 
models.  Rather,  we  wanted  our  model  to  reflect  sound  theory 
and/or  empirical  data  regarding  human  behavior. 

Consequently,  we  wanted  to  base  the  moderator  functions  on 
existing  human  performance  literature. 

The  development  of  these  skill  moderator  functions  will 
be  described  in  detail  in  the  following  section.  The 
functions  and  their  use  are  presented  in  detail  in  MOPADS 
Report  5.10.  To  better  facilitate  an  understanding  of  this 
approach,  let  us  briefly  descrioe  how  they  would  be  used  in  a 
task  network  simulation. 


2-1  Using  the  Moderator  Functions 

The  task  to  the  modeler  is  reduced  to  relatively  few 
activities.  First,  he  or  she  must  identify  the  skills 
involved  in  each  task.  It  is  anticipated  that  some  tasks 
v/ill  involve  more  than  one  skill.  In  this  case,  the  modeler 
must  decide  the  relative  importance  of  each  skill  by 
assigning  a  percentage  to  each  of  the  component  skills  of  the 
task  (the  percentage  must  add  up  to  100  percent). 


Second,  the  modeler  must  develop  a  data  structure  scheme 
to  maintain  the  independent  variables.  In  the  MOPADS 
context,  the  information  is  maintained  in  the  MOPADS  data 
base.  If  these  moderator  functions  are  used  in  another 
setting,  the  data  may  be  maintained  in  any  data  base 
accessible  to  the  moderator  function  module  in  a  standard 
format.  To  accomplish  this,  the  modeler  must  build  the 
following  four  subroutines  to  transfer  the  Values  of  the 
independent  variables  to  the  moderator  function  subroutines: 


1.  GETEVA 

2 .  GETOVA 

3.  GETTSA 

4.  TIMKA 

More  detail  on  the  parameters  which  are  passed  to  and  from 
these  subroutines  are  covered  in  MOPADS  Report  5.10. 

Finally,  the  modeler  must  write  a  small  amount  of 
software  to  identify  the  skills  involved  in  the  task 
currently  being  executed  by  the  model,  call  the  moderator 
function  subroutines  for  these  skills,  and  then  combine  the 
new  estimates  of  the  moan  (if  multiple  skills  are  required  by 
the  task)  into  a  single  weighted  estimate. 

A  specific  task  moderator  function,  which  determines  toe 
modified  value  for  an  individual  task  performance  at  any 
point  in  the  simulation,  will  then  be  represented  by  the 
following  weighted,  sum. 

Moderated  mean 

task  performance  *  M  +  P  A  +  P  A  +  . . . .  P  A 

for  task  t  t  C1  S1  S2  Sn  Sm 


where 

M  -  the  a  priori  mean  value  for  task  performance 

t 

m  -  the  number  of  skills  required  in  the 
performance  of  task  t 

th 

S.  =  the  i  skill  involved  in  t&sk  performance 
(from  the  skill  list  in  Table  .1) 

P  =  the  proportion  of  skill  S  required  in  task  t 
*  - 
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the  value  of  skill  moderator  function  i  at 
this  point  in  the  simulation 


As  the  simulation  proceeds,  the  endogenous  independent 
variables  which  affect  the  value  of  will  change 

reflecting  environmental  or  task  changes.  Between 
simulations,  the  analysts  may  wish  to  change  the  value  of 
exogenous  independent  variables,  such  as  aptitude  or  learning 
variables,  to  examine  their  effect  on  performance. 

As  an  example,  consider  an  assembly  line  inspection  task 
which  is  one  of  several  performed  by  an  operator.  For  this 
particular  task,  the  operator  must  pick  up  an  object,  move  it 
around  in  his  or  her  hands,  check  to  see  if  there  are  any 
flaws  in  the  object  ar.d,  if  so,  decide  whether  to  accept  or 
reject  it.  This  task  involves  three  skills  (from  Table  1): 

1.  Fine  motor  manipulation  (pick  the  object  up 
and  move  it  around) 

2.  Visual  Detection  (check  to  see  if  there  are 
any  flaws) 

3.  Visual  Recognition  (if  there  are  flaws,  decide 
to  reject  or  accept  the  item) 


This  task  may  be  represented  by  one  task  node  in  the  task 
network.  Moreover,  by  watching  ar,  operator  performing  the 
task,  we  determine  that  the  task  requires  30%,  50%,  and  20% 
of  fine  motor  manipulation,  visual  detection,  and  visual 
recognition,  respectively.  Mean  time  to  perform  the  task 
(the  parameter  of  interest)  is  normally  20  seconds.  In  this 
case : 


m  «3  (the  number  of  skills  involved  in  the  task) 

S  ■»  13  (fine  manipulative  ability  from  Table  1) 

1 
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$2  *  2  (visual  detection) 

8^*4  (visual  recognition) 

P.  -  0.-1  / 

1 

P.  -  0.5 

C2 

P.  -  0.2 

C3 

Mt  -  20 

Therefore,  the  moderator  function  for  this  taok  will  be  the 
following: 

Moderated 

task  performance  *  20  +  0.3A^  +  0.5^  +  0.2A^ 

time 


where 


a2 

a4 


f 13  ^X13^ 

f2  (x2) 

f4  <*4> 


where 


the  array  of  independent  variables 
known  to  affect  performance  of  skill 


*  +  1 


For  argument's  sake,  let  us  say  that  A1 ,  «  3,  A  ~  «  -1, 
and  A  , -  5.  At  some  hypothetical  point  in  the  simulation. 
The  moderated  mean  performance  time  vould  equal  the 
following: 

time  -  20  +  .3(3)  +  ,5(--l)  +  .2(5) 

■  21.4  seconds 


It  is  also  worthy  to  note  that  these  moderator  functions 
should  not  be  viewed  as  "sacred  cows  not  to  be  fooled  with." 
In  fact,  we  hope  that  the  moderator  functions  can  continue  to 
develop  and  grow  with  the  state-of-the-art  in  mathematical 
modeling  of  human  performance.  Special  care  has  been  given 
to  document  every  segment  of  code  which  affects  modeled  human 
performance  so  that  the  source  of  that  mathematical 
relationsnip  can  be  determined.  During  the  course  of 
developing  these  subroutines,  many  decisions  had  to  be  made 
as  to  which  model  was  best  and,  therefore,  should  be 
included.  Others  may  justifiably  dispute  these  judgements. 

We  encourage  anyone  wishing  to  change  these  subroutines  to 
do  so.  We  ask  only  that,  if  possible,  these  changes  be 
forwarded  to  the  authors  so  that,  we  may  continue  to  improve 
the  fidelity  cf  the  skill  moderator  subroutines. 


III.  THE  MODERATOR  FUNCTION  DEVELOPMENT  PROCESS 


The  human  factors  literature  is  particularly  weak  in 
most  areas  df  quantitative  human  performance  modeling  and 
prediction.  Therefore,  our  task  was  basically  two-fold. 
First,  we  had  to  review  the  literature  to  locate  articles  and 
publications  which  were  conducive  to  quantitative  human 
performance  modeling.  The  second,  and  more  difficult,  job 
was  to  take  this  conglomerate  of  literature  and  process  it 
into  usable  computer  code. 

For  the  remainder  of  this  section,  we  will  separate  our 
efforts  in  the  development  of  moderator  functions  into  the 
following  five  steps: 

1.  Literature  review 

2.  Development  of  a  computerized  literature  data 
base 

3.  Selection  of  articles/publications  for  use 
in  the  moderator  functions 

4.  Development  of  equations  relating  human 
performance  to  variables  which  affect 
performance 

5.  Development  and  testing  of  moderator  functions 


3-1  Literature  Review 

A  computer  literature  search  was  conducted  on  the  DTIC 
and  Pyschol ogical  Abstracts  files  of  the  DIALOG  data  base. 

The  underlying  search  theme  was  Quantitative  Human 
Perf  ormance  Models.  Also,  an  iterative  search  procedure 
yielded  a  number  of  key  words  which  might  yield  literature 
relevant  to  this  topic.  A  total  of  350  abstracts  were 
reviewed  from  which  115  articles  were  selected  as  potentially 
useful  for  the  proposed  effort. 


N-25 


V, 


V. 


» 


Li 

» 


» 


r — 


During  the  review,  the  reference  sections  of 
particularly  intererting  articles  were  examined.  Those 
references  which  were  not  already  in  the  inventory  were 
ordered  and  also  reviewed.  Two  articles  which  significantly 
affected  the  final  model  were  Siegel  (1979)  and  Pew,  et  al 
(1977). 

All  articles  were  given  a  cursory  review  to  determine 
their  potential  utility.  If  this  review  was  positive,  a  more 
thorough  examination  was  conducted.  This  thorough  review  was 
summarized  on  a  form,  an  example  of  which  is  shown  in  Figure 
II-l. 


Each  model  within  an  article  was  also  summarized  on  the 
form  shown  in  Figure  III-l.  Because  some  articles  included  a 
number  of  human  performance  models,  it  was  frequently  the 
case  that  an  article  was  summarized  on  more  than  one  form. 

The  categories  on  the  forms  are  defined  as  follows: 

1.  Reference.  Information  regarding  author(s), 
title,  and  other  source  data. 

2.  Appropriateness .  A  judgement  was  made  by  the 
reviewer  regarding  the  extent  to  which  this 
article  would  be  useful.  These  judgements 
were  based  upon  two  criteria.  First,  did  the 
article  present  a  significant  contribution  to 
human  performance  modeling?  If  the  answer  was 
yes,  the  article  was  appropriate.  Secondly, 
did  the  article  provide  data  which  would  be 
useful  for  modeling  or  validating  air  defense 
systems?  In  other  words,  while  the  article 
may  not  be  generally  useful  for  modeling, 
could  it  provide  some  task  specific  information? 
If  so,  the  article  was  appropriate. 

3.  Dependent  Variables.  The  specific  dependent 
variabie(s)  defined  by  the  model  is  described. 

4.  Independent  Variables.  Independent  variables 
which  were  included  as  mediators  of  the  dependent 
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Figure  III-l 

FORMS  USED  TO  SUMMARIZE  LITERATURE 

Reference  Phatak,  A.,  Weinert,  H. ,  Segall,  I.,  and  Day,  C.N.  Identification 
of  a  modified  optimal  control  model  for  the  maaan  operator. 
Automatica,  1976,  12,  31-41. 


Approprli  i 

Yes 


Dependant  V.-.riatles 
Tracking 


r.' 


r1 


Independent  Variables 

Operator  gain  vector 
Observation  noise  covariance 


6 


Page 

35-38 

Behaviors 

Tracking 

Quant i tativenes  a 

Functions 

Supporting  Data 


s- 


□  No  Validation 

PH  Validation  with  Questionable  Results 

□  Validated 


Comments 

Simplification  of  the  optimal  control  model 
The  intent  is  to  increase  the  idnntlfiability  of  the  model 
parameters  it  seems  to  have  worked 
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variables  are  defined.  No  units  were  recorded, 
but  a  short  description  was  included. 

Page .  The  paee(s)  where  the  model  was  best 
summarized  was  recorded.  This  was  intended  to 
simplify  future  references  to  the  model. 

Behaviors .  The  general  behavior  categories  which 
were  modeled  were  defined.  These  categories  were 
selected  from  the  taxonomy  in  Table  II-l. 
Normally,  a  model  would  fit  under  only  one 
behavior  category.  If  this  was  not  the  case, 
all  relevant  behavior  categories  were  listed. 

Quant itativeness .  The  degree  of  quantitative 
model  development  was  recorded.  The  lowest 
degree  of  quantitativeness  was  nominal ,  or 
zero  quantitativeness.  This  implied  that  only 
a  verbal  description  of  the  relationship  between 
the  independent  and  dependent  variables  was 
provided.  The  next  level  was  unsealed  graphs, 
in  which  the  independent  and  dependent  variables 
were  presented  as  constructs  without  specific 
units.  The  third  level  was  tables ,  or  scaled 
graphs ,  in  which  units  were  attached  to 
independent  and  dependent  variables.  Finally, 
the  highest  level  was  functional ,  in  which  case 
mathematical  models  were  presented. 

Supporting  Data.  The  extent  to  which  the  model 
was  supported  by  data  was  determined.  If  no  data 
or  references  were  presented,  "No  Validation" 
was  indicated.  If  the  data  were  questionable, 
this  was  also  indicated.  Admittedly,  this 
judgement  was  subjective;  however,  at  some  point, 
this  type  of  judgement  must  be  made. 

Comments .  Additional  comments  were  recorded. 
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3-2  Development  of  a  Computerized  Literature  Data  Base 

To  facilitate  the  development  and  analysis  of  a  data 
base  on  models  of  human  performance,  a  set  of  computer 
programs  and  a  computerized  data  base  were  developed. 

Through  the  use  of  these  programs,  human  performance  models 
can  easily  be  stored  into  the  data  base  and  later  analyzed  in 
a  number  of  different  ways.  This  approach  was  more  practical 
than  hand  recording  of  the  data  because  computer  input  of  the 
data  was  less  time  consuming  than  hand  recording,  and  each 
computer  analysis  required  only  execution  of  a  program, 
whereas  manual  manipulation  would  require  slower  hand 
calculations  and  data  restructuring.  Also,  additions  and 
modifications  to  the  data  base  were  less  cumbersome  using  a 
computerized  data  base. 

Three  programs  were  written  to  create,  modify,  and 
analyze  the  data  bases.  They  are  currently  on  an  Apple  II 
Plus  microcomputer  with  48K  RAM.  These  programs  a>-e  as 
follows : 


1.  ENTER  ARTICLES.  This  program  allows  the  entry  of 
models  from  articles  in  the  open  literature  into 
the  computer  data  base. 

2.  DATA  BASE  ANALYSIS.  This  program  permits  an  exam¬ 
ination  of  the  data  base  to  determine  independent 
variables  which  Affect  skill  categories,  number  of 
times  the  variable  is  referenced,  and  articles 
referencing  the  skill  categories. 

3.  IV  REF  COUNT.  This  program  counts  the  total 
number  o 1  tTmes  that  all  independent  variables 
are  referenced  in  the  data  base. 

For  more  details  on  the  programs,  see  Laughery  (1982a). 


3-3  Selection  of  Articles/Fublications  For  Use  In  The 
Moderator  Functions 

In  many  cases  in  the  literature,  there  were  several 
articles  which  related  skill  performance  to  a  particular 
human  factors  independent  variable  or  sat  of  independent 
variables.  This  provided  two  alternatives  regarding  how  to 
model  that  skill/independent  variable  relationship  in  our 
moderator  functions: 

1.  Take  the  data  and/or  models  from  all  of  the 
articles  and  use  them  simultaneously  (e.g., 
average  the  predicted  results  from  all  of 
the  models). 

2.  Select  one  model  and/or  data  set  and  use  that 
to  link  skill  performance  to  independent 
variables. 

The  first  alternative  was  rejected  because  of  two 
factors.  First,  it  would  necessarily  increase  the  length 
and  execution  time  of  many  moderator  functions.  While 
execution  time  was  not  a  driving  factor  in  moderator  function 
development,  it  was  an  issue  to  which  we  were  sensitive. 
However,  if  the  moderator  functions  were  overly  complex,  as 
they  would  be  if  all  models  were  included,  we  believed  that 
this  would  decrease  the  face  validity  of  the  moderator 
function  approach.  Consequently,  we  elected  the  second 
alternative,  select  one  model  and/or  data  for  inclusion,  as 
our  approach. 

The  selection  of  which  model  ti  include  was  made  by 
considering  the  following  factors: 

1.  Was  the  model  based  on  theory,  data,  or  both? 

2.  Had  a  predictive  validation  study  been  conducted 
on  the  model ? 

We  would  accept  models  which  were  based  upon  data  over  those 
based  strictly  upon  theory.  Additionally,  if  a  model  had 
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been  validated,  we  would  accept  it  over  another  model  which 
had  not. 

There  are  two  other  points  which  should  be  mentioned 
here.  First,  if  interactions  were  involved  we  would  accept  a 
variable  more  than  once.  For  example,  if  variable  A  were 
found  in  two  separate  models  to  interact  with  variables  B  and 
C,  respectively,  then  variable  A  would  be  included  in  both 
models  in  the  moderator  function.  To  do  otherwise  would  have 
required  that  we  "hypothesize  away"  interactions. 

The  second  point  relates  to  the  modular  nature  of  these 
models.  In  each  moderator  function  every  model  is  clearly 
documented  with  respect  to  its  source  including  references 
and  page  numbers.  As  stated  in  the  previous  section,  if  any 
use.*  of  the  moderator  functions  has  a  better  model,  then  that 
model  can  be  substituted  by  changing  ajfew  (e.g. ,  less  than 
five)  lines  of  computer  code.  This  modularity  was  seen  as 
necessary  for  expansion  and  improvements  of  the  moderator 
functions. 


3-4  Development  of  Equations  Relating  Human  Performance  to 
Variables  That  Affect  Human  Performance 


To  say  that  the  human  factors  literature  is  not 
generally  aimed  at  quantitative  human  performance  prediction 
is  to  understate  the  point.  The  human  factors  community  has 
largely  ignored  the  development  of  quantitative  human 
performance  prediction  models  in  favor  of  normative  models 
and  infere>itial  statistical  analysis,  fhere  are,  of  course, 
some  notable  exceptions.  However,  we  have  generally 
contented  ourselves  with  statements  regarding  the  direction 
of  effects  of  variables  affecting  human  performance  without 
attempting  to  determine  the  extent  of  ^he  effect  as  a 
function  of  the  variable's  value.  | 

Perhaps  the  best  examples  of  this  are  the  frequently 
encountered  studies  which  use  regression  analysis  to  analyze 
their  data.  In  many  cases,  a  variety  of  regression 
statistics  were  reported,  including  percent  of  variance 
accounted  for  and  type  I  error  probability;  however,  the 


coefficients  of  the  regression  equation  were  no_t  reported. 
From  the  modeler's  perspective,  the  coefficients  of  the 
regression  equation  are  the  essence  of  the  data. 

Because  of  this  inattention  of  the  human  factors 
literature  to  predictive  model  development,  the  greatest 
portion  of  the  task  of  developing  equations  involved  the 
running  of  statistical  analyses  on  either  raw  data  or 
descriptive  statistics  in  order  to  develop  the  equations. 

Calspan  developed  a  set  of  computer  programs  for  an 
Apple  II  microcomputer  which  allowed  us  to  develop  the 
predictive  models  interactively.  The  programs  were  written 
so  that  when  the  data  from  an  article  or  report  were  entered 
into  the  computer  they  were  automatically  stored  in  a  data 
file  where  they  could  then  be  analyzed  via  one  of  the 
following  seven  methods: 


1. 


3. 


4. 


5. 


6. 


7. 


Simple  Regression  (y  ■  a  +  bx) 

Exponential  Regression  (y  ■  a  +  e^x  ) 

•bx 

Inverse  Exponential  Regression  (y  -  a  +  e  ) 


Squared  Exponential  Regression  (y 


a  +  e 


bxJ 


Inverse  Squared  Exponential  (y  *  a  +  e 
Regression 

2 

Polynomial  Regression  (y  ■  a  +  b^x  +  b2X 
Multiple  Regression  (y  -  a  +  b^x^  +  ) 


) 

) 


where  a  and  b  are  parameters  estimated  from  the 
data,  y  is  the  dependent  variable,  and  x  is  the 
independent  variable. 


Once  the  data  were  stored  in  a  data  file,  they  could  be 
reanalyzed  by  any  of  the  seven  methods  simply  by  specifying 
the  file  name  at  the  beginning  of  program  execution.  The 
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analyses  of  each  data  file  consisted  of  the  following  two 
types  of  information: 


1.  The  summary  statistics  of  the  regression  analysis. 

2.  A  plot  of  the  line  which  would  be  predicted  by  the 
regression  model  vs.  the  data  points  in  the  data 
file  (which  were  used  to  create  the  model).  The 
graph  axes  were  automatically  scaled  to  the  data. 

Examples  of  the  summary  statistics  and  plots  for  each  of  the 
seven  analysis  types  are  included  in  Figures  III-2  through 
III-8.  Printouts  of  each  of  the  seven  computer  programs  (one 
for  each  model  type)  are  included  in  Appendices  A  through  G. 


To  select  the  "best"  equation  (i.e.,  regression  model 
type),  both  the  percent  of  variance  accounted  for  and  a 
visual  examination  of  the  predicted  vs.  actual  points  were 
considered.  The  visual  examination  helped  to  ensure  that  a 
model  was  a  good  predictor  over  the  range  of  values  of  the 
independent  variable.  Additionally,  the  law  of  parsimony  was 
considered  in  that  if  two  models  predicted  equally  well  with 
respect  to  both  variance  and  a  review  of  the  range  of  values, 
the  least  complex  model  was  selected  using  the  following 
order  of  complexity: 


Least  complex 


Most  complex 


Simple  Regression 
Exponential  Regression 
Inverse  Exponential  Regression 
Squared  Exponential  Regression 
Inverse  Squared  Exponential 
Regression 

Polynomial  Regression 
Multiple  Regression 


Finally,  for  those  studies  where  a  predictive  model  was 
presented,  that  model  was  incorporated  into  the  moderator 
functions  without  changes. 
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Figure  III-2 

EXAMPLE  OF  SUMMARY  STATISTICS  AND  PLOTS  FOR 
SIMPLE  REGRESSION 


H j T  RETURN  FOR  PLOT INTERCEPT® . 456424631 
SLOPE=. 031 3859495 


R  SQUARED®. 924742238 

MEAN  OF  X=3 . 3 
MEAN  OF  Y= . 54 

EQUATION 

.454424431  +  .0313858495  *  X 
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Figure  III-3 

EXAMPLE  OF  SUMMARY  STATISTICS  AND  PLOTS  FOR 
EXPONENTIAL  REGRESSION 


ASSYMPTOTE=. 17390425 
SLOPE  =  c  2831 10194 
EXPONENT  =  .0851534923 


R  SQUARED  =  ,843424997 
EQUATION 

.173  +  .283  *  E7P( .085  *  X> 


HIT  RETURN  FOR  PLOT  OF  DATA  AND  FUNC 


i, 
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Figure 1 III-4 

EXAMPLE  Of  SUMMARY  STATISTICS  AND  PLOTS  FOR 
INVERSE  EXPONENTIAL  REGRESSION 


HIT  RETURN  FOR  PLOT  OF  DATA  AND  FUNC 
ASSYMPTOTE=l 3 . 75 
SLOPE  =  -2 . 5931 2365 
EXPONENT  =  . 325059264 


R  SQUARED  =  .99(5386943 

■EQUATION  ! 

13.75  -  2.593  *  EXPC.325  *  X) 

I 


HIT  RETURN  FOR  PLOT  OF  DATA  AND  FUNC 


EXAMPLE  OF  SUMMARY  STATISTICS  AND  PLOTS  FOR 
SQUARED  EXPONENTIAL  REGRESSION 


ASSYMPTOT1-;—? .  659375 
SLOPE  «  9.35758531 
EXPONENT  »  .019792805 7 


R  SQUARED  *  .943534258 
EQUATION 

-7.86  *  9.357  *  EXPC.019  *  X*2  ) 


HIT  RETURN  FOP  PLOT  OF  DATA  AND  FUNC 


Figure  III-6 


EXAMPLE  OF  SUMMARY  STATISTICS  AND  PLOTS  FOR 
INVERSE  SQUARED  EXPONENTIAL  REGRESSION 


ASSYMPTQTE*1 .9390623 
SLOPE  *  -I .10631383 
EXPONENT  «  1 .82133652E-03 

R  SQUARED  *  .723429619 
EQUATION 

1.959  -  1.106  #  EXP<lE-03  *  X‘2> 


MIT  RETURN  FOR  PLOT  OF  DATA  AND  FUNC 


Figure  III-7 

EXAMPLE  OF  SUMMARY  STATISTICS  AND  PLOTS  FOR 
POLYNOMIAL  REGRESSION 


REGRESSION  ANALYSIS 

6<0>«. 433579041 
B<  1  )=*.  053371 1  S91 
B<2>=-3. 62761 549E-03 

R  SQUARED  =  .981618056 

AN  OCA 

SS  DUE  TO  Y». 0384794273 
MS  DUE  TO  Y=. 0192397137 
SS  DUE  TO  ERR0R=7. 205721 92E-04 
MS  DUE  TO  ERR0R=3.60236096E-04 

F<  2,2)=29?.Q4 

EQUATION 

.433  ♦  .058  *  X  ♦  -4E-03  *  XA2 


HIT  RETURN  FOR  PLOT 


Figure  III-8 
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EXAMPLE  OF  SUMMARY  STATISTICS  AND  PLOTS  FOR 
MULTIPLE  REGRESSION 


REGRESSION  ANALYSIS 

B<0>=-14. 8842778 
B<1 >=-2.59297484 
B<2)=4. 31843572 

R  SQUARED  =  .975755838 

AN  OVA 

SS  DUE  TO  Y=774 . 750 1 34 
MS  DUE  TO  Y=387. 375048 
SS  DUE  TO  ERROR=l 9. 2498444 
MS  DUE  TO  ERR0R=4 . 81 244415 

F<2,4)=450 .74 

EQUATION 

-14.885  ♦  -2 . 593*X( 1 ) >  +  4.318*X<2>> 
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3-5  Development  and  Testing  of  Moderator  Functions 


Once  all  of  the  equations  had  been  prepared  for  each 
skill  category,  they  had  to  be  combined  into  FORTRAN 
subroutines  which  represented  the  moderator  function  for  each 
skill  category.  Aside  from  simply  including  all  the 
equations,  two  other  issues  had  to  be  considered  as  well. 

First,  there  was  the  issue  of  whether  some  equations 
should  be  weighted  more  than  others.  We  immediately  decided 
that  there  were  no  readily  justifiable  means  for  subjectively 
or  objectively  weighting  the  quality  of  each  model  (i.e.,  the 
equation).  Therefore,  we  decided  that  the  only  weighting  we 
would  do  would  be  based  upon  the  number  of  independent 
variables  in  the  model.  For  example,  if  one  equation 
included  three  independent  variables,  then  it  would  have 
three  times  more  influence  in  moderating  skill  performance 
than  an  equation  which  included  only  one  independent 
variable.  This  provided  a  roughly  equal  weighting  for  each 
independent  variable. 

Second,  we  had  to  ensure  that  the  final  moderated  skill 
times  or  probabilities  did  not  exceed  legitimate  bounds. 

Times  had  to  be  greater  than  zero  and  probabilities  had  to 
range  between  zero  and  one. 

Once  the  FORTRAN  subroutine  was  completed  and  loaded 
into  the  computer,  debugging  and  sensitivity  testing 
commenced.  Sensitivity  testing  simply  involved  manipulating 
each  of  the  independent  variables  used  in  a  routine  to 
determine  if  that  moderated  skill  performance  behaved 
reasonably.  For  example,  if  increased  sleep  deprivation  led 
to  improved  performance,  the  odds  were  good  that  there  was 
either  a  model  development  or  coding  error.  As  errors  were 
identified,  the  software  was  reviewed  and  corrected. 

Currently,  all  software  has  been  debugged  and 
sensitivity  tests  conducted.  The  next  step  would  logically 
be  a  study  of  the  predictive  validity  of  one  or  several  of 
the  functions  in  an  operational  environment.  Unfortunately, 


neither  the  MOPADS  operator  computer  models  nor  real-world 
data  were  available  at  the  completion  of  this  study  for  thi 
analysis. 


IV.  ADVANTAGES  AND  DISADVANTAGES 
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The  advantage  of  !;he  approach  described  in  the  previous 
chapters  is  expected  to  be  higher  fidelity  simulation.  If 
assessment  of  human  performance  is  one  of  the  simulation 
objectives,  this  approach  will  allow  more  accurate  simulation 
of  performance  under  a  variety  of  conditions.  The  model  will 
behpve  more  like  humans  behave  than  it  would  if  static  task 
performance  parameters  were  used. 

| 

!  An  ancillary  advantage  is  that  it  does  not  require  a 
human  performance  modeling  expert.  Once  the  task  network  is 
created,  all  that  is  required  of  the  analyst  is  to  specify 
the  skills  required  for  each  task  (from  the  predetermined 
list  presented  in  Table  1-1)  and  the  proportion  of  each  skill 
for  task  performance.  Then,  the  skill  moderator  functions 
wilj.  be  used  to  automatically  manipulate  task  performance 
parameters.  The  skill  moderator  functions  have  been 
developed  modularly  so  that  they  may  be  improved  as  the  human 
factors  profession  gains  more  knowledge  about  quantitative 
human  performance  modeling.  That  is,  as  better  data  become 
available  linking  the  independent  variables  to  consequent 
skill  performance,  these  data  can  be  translated  into  models 
and  these  models  can  be  incorporated  into  the  moderator 
function  software.  The  software  is  well  documented  in  this 
regard. 

The  primary  disadvantage  is  that  the  subroutines  require 
the  additional  human  factors  independent  variables  to  be 
included  in  the  computer  model.  Endogenous  variables  will 
have  to  be  updated  during  the  simulation  and  exogenous 
variables  will  need  to  be  specified.  This  can  be  a 
formidable  task.  The  current  moderator  functions  have  been 
designed  to  accommodate  default  values  so  the  analyst  may 
"skip"  some  human  factors  variables,  if  desired.  However,  if 
the  modeler  wants  improved  fidelity,  he  or  she  must  pay  for 
it  with  the  maintenance  of  additional  variables.  However,  in 
any  simulation,  the  modeler  must  be  prepared  to  maintain  the 
variables  that  he  or  she  wishes  to  study. 
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Tha  other  current  disadvantage  is  the  absence  of  a 
predictive  validation  study.  The  skill  moderator  functions 
have  internal  validity  in  that  they  were  developed  from 
validated  human  performance  models  or  data  in  the  open 
literature.  However,  the  "bottom  line"  of  predictive 
validity  is,  as  yet,  undetermined. 
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COMPUTER  PROGRAM  USED  FOR 
SIMPLE  REGRESSION 
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5  LOHEM:  14385 
10  D*  =  CHR$  <.4) 

15  DIM  D<2.200; 

20  PRINT  “ENTER  NAME  OF  DATA  BASE  FOR  ANALYSIS":  PRINT  "  OR  'RETURN'  IF 
DATA  ARE  TO  BE  " :  PRINT  "  ENTERED  MANUALLY" 

20  INPUT  OS*:  IF  LEN  <DS$)  <  1  GOTO  500 
35  ONERR  GOTO  40 

40  PRINT  D* ; “OPEN  ";DS*:  PRINT  D*;"READ  *;DS*:  INPUT  ND:  POKE  214. 0:N  = 
ND  /  2:FL  3  1 :  GOTO  500 
:0  IF  PEEK  (222)  <  )  5  THEN  STOP 

70  POKE  214,0 

•30  PRINT  :  PRINT  "THIS  DATA  SET  DOES  NOT  CURRENTLY  EXIST":  PRINT  "  ENTER 
DATA  TO  CREATE  IT  OR  HIT":  PRINT  "  'RETURN'  TO  EXIT  THE  PROGRAM" 

•rO  1  =  0:  DIM  A*(500) 

1 00  PRiNT 

!10  PRINT  "  TYPE  '%%'  TO  QUIT" 

.20  PRINT  “  TYPE  '  *B'  TO  BACKUP" 

;  25  PRINT  “IND  VARS  ARE  ODD  ENTRIES":  PRINT  "DEP  VARS  ARE  EVEN  ENTRIES1' 
30  I  =  I  +  1 
! 40  PRINT  “INPUT  #";I 
; 50  INPUT  A* < I > 

; 55  IF  I  =  1  AND  Ai(I)  =  "“  THEN  PRINT  D*; “DELETE  ";DS*:  STOP 
:40  IF  AT < I )  =  “TB"  THEN  1=1-1:  GOTO  140 
1 70  IF  A$(I)  »  “*<*“  GOTO  200 
.30  GOTO  100 
; 90  PRINT 

.00  PRINT  04: "OPEN  “;DS* 

210  PRINT  D$ ; “WRITE  ";DS4 
220  PRINT  I  -  1 
230  FOR  J  =  1  TO  I  -  1 
240  PRINT  A*(J) 

250  NEXT  J 

240  PRINT  D4; "CLOSE  ";DS4 
270  GOTO  40 

300  REM  BEGIN  REGRESSION 

310  IF  FL  =  0  THEN  INPUT  "NUMBER  OF  DATA  PAIRS  " jN 
520  FOR  I  =  1  TO  N 

530  IF  FL  =  0  THEN  PRINT  “  DATA  PAIR  #";I;"  (IND  VAR,  DEP  VAR)" 

540  INPUT  A,B:DU,I)  =  A:D(2.I)  =  B 

550  A1  =  A1  +  A :A2  =  A2  +  A  *  A:B1  =  Bi  +  B:B2  =  B2  +  B  *  B :AB  =  AB  +  A  * 

B 

540  NEXT  I 

545  PRINT  D$j “CLOSE" 

570  SX  =  A2  -  <A1  *  Al)  /  N 

580  SY  =  B2  -  (Bl  «  Bl)  /  N 

590  SP  =  AB  -  ((Al  *  Bl)  /  N) 

400  Al  =  Al  /  N : B 1  =  Bl  /  N 

410  HOME  :  PRINT  “ INTERCEPTS ;B1  -  (SP  /  SX)  *  Al 
420  IC  =  Bl  -  (SP  /  SX)  »  Al 
430  PRINT  "SlOPE=“;SP  /  SX 
440  SL  =  SP  /  SX 

450  PRINT  :  PRINT  :  PRINT  "  R  SQUARED3’ : ( SP  *  SP)  /  (SX  »  SY) 
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660  PRINT  :  PRINT  "MEAN  OF  X=“ ;A1 :  PRINT  "MEAN  OF  Y=“;81 

665  PRINT  :  PRINT  “EQUATION" 

666  DRINT  IC;"  +  ";SL:"  *  X":  PRINT 
670  INPUT  "HIT  RETURN  FOP  PLOT" :Q* 

680  DEP  FN  RG(WW)  =  IC  +  :'L  *  UW 
690  T7  =  270:05  =  150:01  =  1 

700  LX  =  99999 :LY  =  99999 :HX  =  -  99999 \ HY  =  -  99999 

710  FOR  I  =  1  TO  N 

720  PRINT  D(l,i>,D(2.I>.  FN  RG(D(1,I>) 

730  IF  DU,  I)  >  HX  THEN  HX  =  D<1,I) 

740  IF  DU, I)  <  LX  THEN  LX  =  D<  1  , 1 ) 

750  IF  D<2 , 1 7  <  LY  THEN  LY  =  D<2,I) 

760  IF  D(2, I )  >  HY  THEN  HY  =  D<2,I) 

770  IF  FN  R6(D< 1,1))  >  HY  THEN  HY  =  FN  R6<D(1,I)> 

780  IF  FC  RG< D< 1,1))  <  LY  THEN  LY  =  FN  RG(D(1,I)) 

790  NEXT  1 

000  LX  -  LX  -  0.1  *  < HX  -  LX) 

810  HX  *  HX  +  0.1  *  (HX  -  LX) 

320  LY  a  LY  -  0.1  *  (HY  -  LY) 

330  HY  -  HY  +  0.1  *  (HY  -  LY) 

340  H6R  :  HCOLOR=  3:  HPLOT  0,0  TO  0.150  TO  270.150  TO  270,0 

350  FOR  I  =  1  TO  140  STEP  10 

360  HPLOT  0.1  TO  5.1:  HPLOT  265,1  TO  270,1 

370  NEXT  I 

380  FOR  I  =  10  TO  270  STEP  10 
390  HPLOT  1,145  TO  1,150 
>00  NEXT  I 

>10  NX  =  270  /  (HX  -  LX) :MY  =  150  /  (HY  -  LY) 

■'20  FOR  I  =  1  TO  N 

•■>0  HPLOT  (D(l,  I)  -  LX)  *  MX,  150  -  (C(2.I>  -  LY)  *  MY 
>40  NEXT  I 

>50  FOR  I  =  15  TO  255 

>60  HPLOT  I  -  01 ,05  -  (  FN  RG((I  -  01)  /  MX  +  LX)  -  LY)  *  MY  TO  I  ,05  -  < 

FN  RG( I  /  MX  +  LX)  -  LY)  *  MY 
>70  NEXT  I 

980  LX  =  INT  (LX  *  100)  /  100:LY  =  1NT  (LY  *  100)  /  1 0 0  : HX  =  INT  (HX  * 
100)  /  100: H Y  =  INT  (HY  *  100)  /  100 
985  UTAB  21:  PRINT  "FILE=“;DS$:  PRINT  "LCW  X  VALUE=“;LX;  TA8(  21 "HIGH 
X  VALUE=" jHX:  PRINT  "LOW  Y  WALUE=“;LY;  TAB(  21 ) ; ” HI GH  Y  VALUE=" ;HY 
>90  INPUT  "HIT  RETURN  TO  CONTINUE,  TO  END" ; QW* :  IF  GW*  =  ”E"  THEN  TEXT 
:  END 
1000  TEXT 
1010  GOTO  610 
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COMPUTER  PROGRAM  USED  FOR 
EXPONENTIAL  REGRESSION 
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5  LOMEMi  16385 
10  W  ■  CHR*  <  4) 

20  PRINT  "ENTER  NAME  OF  DATA  BASE  FOR  ANALYSIS" s  PRINT  "  OR  'RETURN'  !F 
DATA  ARE  TO  BE  ‘I  PRINT  "  ENTERED  MANUALLY* 

30  INPUT  DSI:  IF  LEN  (DSI)  <  1  GOTO  500 
35  QNERR  GOTO  60 

40  PRINT  Dl : "OPEN  ";DSl!  PRINT  Dl  5 " READ  ";DSl!  INPUT  ND:  POKE  216 
NO  /  2:FL  »  1 :  GOTO  500 
60  IF  PEEK  (222)  <  >  5  THEN  STOP 

70  POKE  21 6. C 

80  PRINT  :  PRINT  "THIS  DATA  SET  DOES  NOT  CURRENTLY  EXIST’!  PRINT 
DATA  TO  CREATE  IT  OR  HIT"!  PRINT  *  'RETURN'  TO  EXIT  THE  PROG 
90  I  »  0:  DIM  AK500) 

100  PRINT 

110  PRINT  "  TYPE  'll'  TO  QUIT* 

120  PRINT  *  TYPE  'IB'  TO  BACKUP*  t 

125  PRINT  "IND  VARS  ARE  ODD  ENTRIES"!  PRINT  "DEP  VARS  ARE  EVb,  EN 
130  I  *  1  ♦  1 
140  PR  I  ITT  "INPUT  #"  5 1 
150  INPUT  A*(I) 

155  IF  1  »  1  AND  AI(I)  »  *"  THEN  PRINT  Dl; "DELETE  "jDSl!  STOP  ( 

160  IF  Aid)  =  r*B"  THEN  1*1-1!  GOTO  140  j 

170  IF  AKI)  =  "II"  GOTO  200  f 

180  GOTO  100  I 

190  PRINT  j 

200  PRINT  Ms  "OPEN  "jDSI  •  ] 

210  PRINT  Dl! "WRITE  “jDSI  S  ( 

2 20  PRINT  I  -  1 
230  FOR  J  a  1  TO  I  -  1 
240  PRINT  AI(J) 

250  NEXT  J 

260  PRINT  Dl 5 "CLOSE  ";DSI 
270  GOTO  40 

500  H  =  -  9999:1  a  99 99 

510  DIM  D( 2,500 ) 

520  IF  FL  =  0  THEN  INPUT  "NUMBER  OF  DATA  PAIRS" ;N 
530  FOR  I  =  1  TO  N 

540  IF  FL  «  0  THEN  PRINT  *  DATA  PAIR  4";1;"  <IND  VAR,  DEP  VAR)" 

550  INPUT  D< 1 , 1 ) ,D< 2, 1 ) 

560  IF  D(2,I )  >  H  THEN  H  a  D(2,I) 

570  IF  D(2, I )  <  L  THEN  L  =  D(2,I) 

580  NEXT  I 

585  PRINT  D$;"CL0SE":  HOME 
600  DIM  EX ( 5 ) : CV  =  .001  :SN  =  25 


<> 

216.0:1^  > 


•  Enter 
ra/i* 

/ 


520  IF  FL  =  0  THEN  If 
530  FOR  I  =  1  TO  N 
540  IF  FL  *  0  THEN  PF 
550  INPUT  D<1 ,1) ,D(2,1 
560  IF  D(2,I)  >  H  THEf 
570  IF  D(2, I )  <  L  THEf 
580  NEXT  I 

585  PRINT  DIs’CLGSE" : 
600  DIM  EX ( 5 ) : CV  =  .01 
610  IR  *  1 

o20  HI  a  L :LI  =  2  *  L  ■ 
630  EXd)  =  0 
640  EX<5>  =  0 
*45  SI  *  HI  -  LI 
*50  C  »  LI  ♦  .5  *  SI 
*60  GOSUB  10009 :EX<3) 


*  DATA  PAIR  4" 5 1 ;  *  <IND  VAR,  DEP  VAR)" 

D<2, I ) 

D(  2 , 1 ) 
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C  *  LI  ♦  .25  #  SI:  GOSUB  10000:EX<2>  *  R2 
O'-  LI  ♦  .75  #  SI:  bOSUB  10000 :EX(4)  »  Rk 
*  -  999 

f  FOR  I  a  2  TO  4 

IF  EX( I )  >  BL  THEN  BS  »  1 i&J  *  EX(I) 

NEXT  I 

AX  *  EX( BS  -  1 > :AY  ■  EX(BS):AZ  *  EXCBS  ♦  1) 

EXO  »  AX:EX( 3)  -  AY:EX<5>  »  «Z 

1R  ■  1R  ♦  1 

LI  »  LI  ♦  (BS  -  2)  #  .25  *  SI :SI  «  SI  /  2.0 
IF  EX< 3)  -  EX< 1 )  <  CV  OR  EX(3>  -  EX<5>  <  CV  SOTO  1000 
IF  1R  •  SN  GOTO  1000 
GOTO  700 

I  C  -  LI  ♦  SI  /  2 
I  FOR  I  »  1  TO  N 

I  A  -  0< 1 .1) :B  -  LOG  (0(2,1)  -  C) 

I  A1  =•  A1  ♦  A:A2  »  A2  ♦  A  *  A:B1  *  B1  ♦  B:B2  «  82  ♦  B  *  BiAB  *  AB  ♦  A  * 
B 

I  NEXT  I 

I  SX  *  A2  -  (A1  #  AJ )  /  N 

I  SY  «  B2  -  (81  *  Bl>  /  N 

I  S?  ■  AB  -  <(A1  *  B1 )  /  N> 

I  A1  *  A1  /  N : B 1  «  81  /  N 
I  SL  »  61  -  <SP  /  SX)  *  A1 

I  SL  «  EXP  (SL) 

I  EX  *  SP  /  SX 

PRINT  “NUMBER  OF  ITERATIONS35* ; I R  -  1:  PRINT 
PRINT  :  PRINT  “ASSYMPTOTE=* ;C 
PRINT  "SLOPE  =  * ; SL :  PRINT  "EXPONENT  =  “;EX 
R2  =  (SP  *  SP)  /  (SX  *  SY) 

PRINT  :  PRINT  :  PRINT  "  R  SQUARED  =  * ;R2 

PRINT  :  PRINT  *EQl|ATION":  PRINT  *  “;  INT  (C  *  1000)  /  1000:*  +  *?  INT 
(SL  *  1000)  /  10001*  *  EXP< * ;  INT  (EX  *  1000)  /  1000;"  *  X)*:  PRINT 

PRINT  :  INPUT  *Hli  RETURN  FOR  PLOT  OF  DATA  AND  FUNC“;Q* 
i  DEF  FN  RG(WU)  =  Q  +  SL  »  EXP  (EX  *  WW) 

T7  =  270:05  =  150:01  =  1 

LX  =  9999? :LY  =  99999 :HX  =  -  99999 :HY  =  -  99999 

FOR  I  =  1  TO  N  i 

IF  0(1,1)  >  HX  THEH  HX  =  D(1,I)  j 

IF  D(1 ,1)  <  LX  THEfc  LX  =  0(1,1) 

IF  D( 2 , I )  <  LY  THE^  LY  =  0(2, I) 

IF  D< 2 , 1 )  >  HY  THEN  HY  *  0(2,1) 

IF  FN  RG(D(1  ,D)  \  HY  THEN  HY  3  FN  RG(D(  1,1)) 

IF  FN  RG(D(  1,1))  \  LY  THEN  LY  FN  RG(D(1,I)) 

NEXT  I  I 

LX  *  LX  -  0.1  *  (HX  j-  LX) 

HX  *  HX  +  0.1  *  (HX  f  LX) 

IV  a  IY  -  d.l  #  ( HY  -  I  Y) 


FN  RG(D( 1 , I ) ) 
FN  RG(D(1,I>) 


LY  a  LY  -  0.1  #  ( HY  -  LY) 

HY  =  HY  ♦  0.1  *  (HY  -  LY) 

HGR  :  HCOLOR=  3:  HPLOT  0.0  TO  0.150  TO  270,150  TO  27C,0 

FOR  I  *  1  TO  140  STEP  10 

HPLOT  0,1  TO  5,1:  HPLOT  265,1  TO  270,1 

NEXT  I 
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1*60  FOR  I  -  1C  TO  270  STEP  10 
K70  HPLQT  1,145  TO  1,150 
1480  NEXT  1 

1490  MX  -  270  /  < HX  -  LX) :MY  =  150  /  <HY  -  LY) 

1500  FOR  1  »  1  TO  N 

1510  HPLOT  <D< 1  . 1 )  -  LX)  *  MX, 150  -  <D(2.I>  -  LY)  »  MY 

1520  NEXT  I 

1530  FOR  1  »  25  TO  250 

1540  HPLOT  I  -  01.05  -  (  FN  RG((I  -  01)  /  MX  ♦  LX)  *  LY)  *  MY  TO  1,05  - 
<  FN  RGCI  /  MX  v  LX)  -  LY)  #  MY 
1550  NEXT  I 

1560  LX  =  INT  (LX  *  100)  /  100:LY  a  l NT  <LY  *  100)  /  lOOsHX  «  INT  (HX  » 
100)  /  lQO.-HY  »  int  <HY  *  100)  /  100 
1570  VTA8  21s  PRINT  *FILE*“;DS$:  PRINT  "LOW  X  VALUE=“;LX;  TAB<  21 )} "HIGH 
X  VALUE*" ;HXs  PRINT  "LOU  Y  VALUE** ;LY j  TAB(  21 ) ; “HIGH  Y  VALUE** ;HY 
1580  INPUT  “HIT  RETURN  TO  CONTINUE,  'E'  TO  END‘;GW*!  IF  GW*  *  “E“  THEN  TEXT 
:  END 

1590  TEXT  s  GOTO  1220 

10000  FOR  I  *  1  TO  N 

10860  A  a  0(1 ,1) :B  =  LOG  < D< 2 , 1 >  -  C) 

10370  A1  *  A1  ♦  A:A2  *  A2  ♦  A  *  A:B1  »  B1  ♦  B :B2  =  B2  +  B  *  B:AB  *  AB  ♦  A 
*  B 

10880  NEXT  I 

10890  SX  a  h2  -  (A1  *  Al)  /  N 
10900  SY  ». 82  -  ( B1  *  Bl)  /  N 
11000  SP  a  A8  -  ((Al  *  Bl)  /  N) 

11500  R2  *  (SP  *  SP)  /  (SX  *  SY) 

12000  Al  =  0:a2  =  0 : B 1  *  0s82  »  0:AB  «  o 
12020  RETURN 
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COMPUTER  PROGRAM  USED  FOR 
INVERSE  EXPONENTIAL  REGRESSION 


5  LOMEN:  14385 
10  D*  =  CHRi  <4) 

20  PRINT  "ENTER  NAME  OF  DATA  BASE  FOR  ANALYSIS":  PRINT  ■  OR  'RETURN'  IF 
DATA  ARE  TO  BE  PRINT  *  ENTERED  MANUALLY" 

3C  INPUT  DSi:  IF  LEN  (0S»)  <  1  GOTO  500 
35  ONERR  GOTO  40 

40  PRINT  0* ; " OPEN  “;DSi:  PRINT  Di;"READ  *;DSi:  INPUT  ND:  POKE  214, 0:N  » 
ND  /  2:FL  53  1 :  GOTO  500 
40  IF  PEEK  (222)  <  )  5  THEN  STOP 

70  POKE  214,0 

80  PRINT  :  PRINT  "THIS  DATA  SET  DOES  NOT  CURRENTLY  EXIST":  PRINT  "  ENTER 


5 

DATA  TO  CREATE 

90  I 

=  0:  DIM  Ai(5Q0) 

V; 

100 

PRINT 

110 

PRINT  "  TYPE  'ii 

P 

120 

PRINT  "  TYPE  'iB 

$ 

125 

PRINT  "IND  VARS  i 

130 

1 

1  =  1  +  1 

rsr%  t-r  i  tkinin  i>  ■ 

150  INPUT  Aid ) 

155  IF  I  =  1  AND  Aid )  a  “"  THEN  PRINT  Di j "DELETE  ";DSi:  STOP 
140  IF  Aid)  =  "iB"  THEN  1  =  1-1:  GOTO  140 
170  IF  Aid)  =  "ii"  GOTO  200 
180  GOTO  100 
1 9C  PRINT 

200  PRINT  D* ; "OPEN  ";DSi 
210  PRINT  Di; "WRITE  “jDSi 
220  PRINT  I  -  1 
230  FOR  J  =  1  TO  .  -  1 
240  PRINT  Ai( J) 

250  NEXT  J 

240  PRINT  Oi;" CLOSE  ";DSi 
270  GOTO  40 

500  H  =  -  9999 :L  =  9999 

510  DIM  D(2,500) 

520  IF  "L  =0  THEN  INPUT  "NUMBER  OF  DATA  PAIRS" ;N 
530  FOR  I  =  1  TO  N 

540  IF  FL  =  0  THEN  PRINT  “  DATA  PAIR  #" j I ; "  < IND  VAR,  DEP  VAR)" 
550  INPUT  Dd  ,1)  ,0(2,1) 

540  IF  D(2, 1 )  >  H  THEN  H  =  0(2,1) 

570  IF  D(2,I)  <  L  THEN  L  =  D(2,I) 

580  NEXT  I 

585  PRINT  Di ; "CLOSE" :  HOME 
400  DIM  EX(5) :CV  =  .001 sSN  =  25 
410  1R  =  1 

420  LI  =  H:HI  =  2  *  H  -  L 

430  EXd)  =  0 

440  EX(5)  =  0 

445  SI  =  HI  -  LI 

450  C  =  LI  ♦  .5  #  SI 

440  GOSUB  10000 :EX(3)  =  R2 

700  C  =  LI  +  .25  *  SI:  GOSUB  1 0000 : £X< 2)  =  R2 

710  C  =  LI  +  .75  *  SI:  GOSUB  10000:£X<4)  =  R2 

720  BV  =  -  999 
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730  FOR  I  -  2  TO  4 

740  IF  EX<  I )  >  BM  THEN  BS  »  1:80  ■  EX<I> 

730  NEXT  I 

760  AX  *>  EX<BS  -  1 )  :AY  *  EX(BS):AZ  «  EX(BS  +  1) 

"’70  EX(1)  *  AX:EX(3)  =  AY:EX(5)  *  A2 

790  IR  3  ir  ♦  i 

300  LI  *  LI  ♦  < BS  -  2)  *  .25  *  SI sSI  »  SI  /  2.0 

610  IF  EX(3)  -  EX< 1 )  <  CV  OR  EX<3)  -  EX(5)  <  CV  GOTO  1000 

815  IF  IR  *  SN  GOTO  1000 

820  GOTO  700 

1000  C  »  LI  ♦  SI  /  2 

1100  FOR  I  *  1  TO  N 

1110  A  »  DCl'DsB  *  LOG  <C  -  0(2, I)> 

1130  A1  »  A1  ♦  A:A2  ■  A2  +  A  *  A:B1  *  BI  ♦  B:B2  *  B2  ♦  B  *  B:AB  *  AB  +  A  * 

B 

1140  NEXT  I 

1150  SX  *  A2  -  <A1  *  Al)  /  N 

1160  SY  *  82  -  <B1  #  Bl)  /  N 

1170  SP  *  hB  -  <<A1  *  BfH)  /  N)  1 

1180  Al  *  Al  /  N: Bl  *  81  /  N 

1190  SL  »  81  -  (SP  /  SX)  *  Al 

1200  SL  *  EXP  (SL) 

1210  EX  *  SP  /  SX 

1215  PRINT  ‘NUMBER  OF  ITERATIONS** :  IR  -  Is  PRINT 
1220  PRINT  :  PRINT  “ASSYMPTOTE=“ ;C 
1230  PRINT  ‘SLOPE  =*  ‘ ;  -  SL s  PRINT  ‘EXPONENT  *  ‘;EX 
1235  R2  *  (SP  *  S?)  /  (SX  *  SY) 

1240  PRINT  :  PRINT  :  PRINT  *  R  SQUARED  *  ";R2 

1245  PRINT  :  PRINT  “EQUATION* :  PRINT  "  INI  <C  *  1000)  /  1000;"  -  *;  INT 

(SL  *  1000)  /  1000;“  *  EXPC;  INT  (EX  *  1000)  /  1000;‘  »  X)‘s  PRINT 

1250  PRINT  ;  INPUT  “HIT  RETURN  FOR  PLof  OF  DATA  AND  F'JNC‘;QS 

1260  DEF  FN  RG(WU)  »  C  -  SL  *  EXP  (EX  *  WU> 

17/1  T7  =  270:05  *  150:01  *  1 

1280  LX  =  99<>99  :LY  =  99999  :HX  =  -  99999 :HY  =»  -  99999 

1290  FOR  I  »  1  TO  N  1 

1310  IF  D( 1 , I )  >  HX  THEN  HX  =  D(1,I)  | 

1320  IF  D(1,I)  (  LX  THEN  LX  =  0(1, I) 

1330  IF  D( 2 , 1 )  (  LY  THEN  LY  *  0(2,1) 

1340  IF  D(2, I )  >  HY  THEN  HY  =  0(2,1) 

1350  IF  FN  RG(D(  1 , ! ) )  >  HY  THEN  HY  =  FN  RG(D(1,D) 

1360  IF  FN  RG(D(  1,1))  (  LY  THEN  LY  =  FN  RG(D(1  ,D)  , 

1370  NEXT  I 

1380  LX  *  LX  -  0.1  »  (HX  -  LX) 

1390  HX  *  HX  +  0.1  #  (HX  -  LX) 

1400  LY  =  LY  -  0.1  *  (HY  -  LY) 

1410  HY  -  HY  ♦  0.1  *  (HY  -  LY) 

1420  HGR  :  HCOLOR=  3:  HPLOT  0,0  TO  0,150  TO  270,150  TO  270,0  j 

1430  FOR  I  *  1  TO  140  STEP  10  ! 

1440  HPLOT  0,1  TO  5,1:  HPLOT  265,1  TO  270,1 
1450  NEXT  I 

1460  FOR  I  =  10  TO  270  STEP  10 
1470  HPLOT  1.145  TO  1,150 
1480  NEXT  I 
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1490  MX  *  270  /  <HX  -  LX) :MY  *  150  /  <HY  -  LY) 

1500  FOR  I  *  1  TO  N 

1510  HPLOT  <0(1, 1)  -  LX)  *  MX, 150  -  <D<2,I>  -  LY)  *  MY 

1520  NEXT  I 

1530  FOR  1  *  25  TO  250 

1540  HPLOT  1  -  01.05  -  <  FN  R6<<I  -  01)  /  MX  ♦  LX)  -  LY)  »MYT0I,05- 
<  FN  RGCI  /  MX  ♦  LX)  -  LY)  *  MY 
1550  NEXT  I 

1560  LX  *  INT  <LX  #  100)  /  100:LY  *  1NT  <LY  *  100)  /  lOOsKX  »•  INT  <HX  * 
100)  /  100:HY  ■  INT  <HY  *  100)  /  100 
1570  VTA3  21s  PRINT  'FILE»*;DS*s  PRINT  *LOU  X  VALUE*" ; LX ;  TAB<  21)} "HIGH 
X  VALUE**  jHXs  PRINT  *LOU  Y  VALUE** jLY*  TAB<  21 ) ; “HIGH  Y  VALUE** }HY 
1580  INPUT  ‘HIT  RETURN  TO  CONTINUE,  'E'  TO  END*  ;QW*:  IF  GW*  -  "E*  THEN  TEXT 
:  END 

1590  TEXT  s  GOTO  1220 

:gooo  for  i  *  i  to  n 

>960  A  *  D < I . I ) :B  *  LOG  <C  -  D<2,I>) 

. '.870  A1  *  A1  +  AsA2  ■  A2  ♦  A  *  A:B1  ■  Bl  ♦  8:B2  *  B2  ♦  D  #  BsAB  *  AB  ♦  A 
*  B 

J380  NEXT  I 

•690  SX  *  A2  -  <A1  *  Al)  /  N 

. ,900  SY  -  B2  -  ( Bl  #  Bl)  /  N 

. 1000  SP  *  AB  -  < (Al  *  Bl)  /  N) 

11500  R2  *  (SP  *  SP)  /  (SX  *  SY) 

.2000  Al  *  0 :A2  *  0:81  *  0:32  *  OsAB  »  0 
12020  RETURN 
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Appendix  D 

COMPUTER  PROGRAM  USED  FOR 
SQUARED  EXPONENTIAL  REGRESSION 


V 


F 

m  n 

t: 
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5  LOMEMs  14335 
10  M  =»  CHR*  < 4) 

20  PRINT  "ENTER  NAME  OF  DATA  BASE  FOR  ANALYSIS":  PRINT  *  OR  'RETURN'  IF 
DATA  ARE  TO  St  ":  PRINT  *  ENTERED  MANUALLY* 

30  INPUT  DS*:  iF  LEN  <DS$)  <  1  COTO  500 
35  ONERR  GOTO  60 

40  PRINT  D* ; " OPEN  ":DS$:  PRINT  D*(*READ  *;DS*:  INPUT  ND:  POKE  216.0 :N  3 
ND  /  2:FL  3  1 :  GOTO  500 
60  IF  PEEK  <222)  <  >  5  THEN  STOP 

70  POKE  216.0 

80  PRINT  :  PRINT  "THIS  DATA  SET  DOES  NOT  CURRENTLY  EXIST":  PRINT  "  ENTER 
DATA  TO  CREATE  IT  OR  HIT":  PRINT  "  'RETURN'  TO  EXIT  THE  PROGRAM" 

90  I  3  0:  DIM  A*<503) 

100  PRINT 

110  PRINT  "  TYPE  '**'  TO  QUIT* 

120  PRINT  "  TYPE  '$B'  TO  BACKUP* 

125  PRINT  “IND  VARS  ARE  ODD  ENTRIES’:  PRINT  *DEP  VARS  ARE  EVEN  ENTRIES" 

130  I  3  I  ♦  1 

140  PRINT  "INPUT  #“sl 

150  INPUT  A$< I ) 

155  IF  I  =  1  AND  A$< I )  3  ""  THEN  PRINT  D^ ; "DELETE  ";DS*:  STOP 

160  IF  Aid)  3  “*B"  THEN  I  3  I  -  1:  GOTO  140 

170  IF  A*<I)  3  "*$"  GOTO  200 

130  GOTO  100 

190  PRINT 

200  PRINT  Di 5 " OPEN  " ;DS* 

210  PRINT  D* ( "WRITE  “;DS* 

220  PRINT  I  -  1 

230  FOR  J  3  1  TO  I  -  1 

240  PRINT  A*<J) 

250  NEXT  J 

26fr  PRINT  D*;" CLOSE  " ; DS^ 

270  GOTO  40 

500  H  3  -  99?9:L  3  9999 

510  DIM  D<2,500) 

520  IF  FL  =  0  THEN  INPUT  "NUMBER  OF  DATA  PAIRS’ ;N 
330  FOR  I  3  1  TO  N 

340  IF  FL  =  0  THEN  PRINT  “  DATA  PAIR  #*;1;’  <IND  VAR,  DEP  VAR)" 

350  INPUT  D( 1 , 1 ) ,D<2, 1 ) 

360  IF  D<2, 1 )  >  H  THEN  H  3  D<2,I) 

570  IF  D(2, 1 )  <  L  THEN  L  =  D< 2 , 1 > 

580  NEXT  I 

585  PRINT  D* j "CLOSE" :  HOME 
nOO  DIM  EX<5) :CV  =  .001 :SN  3  25 
610  IR  3  1 

620  HI  =  L  J  LI  3  2  *  L  -  H 

630  EX< 1 '  3  0 

640  EX(5)  3  0 

645  SI  3  HI  -  LI 

: 50  c  3  LI  +  .5  *  SI 

.60  GOSUB  i0000:EX(3)  3  R2 

-00  C  3  LI  +  .25  *  SI:  GOSUB  10000:EX<2)  3  R2 

710  C  3  LI  ♦  .75  ♦  SI.  GOSUB  10000:EX<4)  3  R2 


720  eu  =  -  99? 

720  FOR  I  »  2  TO  4 

740  IF  EX< I )  >  BV  THEN  BS  =  I :BV  =  EX(1) 

750  NEXT  1 

760  AX  =  EX ( BS  -  1 ) ;AY  =  EX(BS) :AZ  =  EX(BS  +  1) 

770  EX(1)  =  AX :  EX <  3 )  =  AY:B«5)  =  AZ 
790  IR  =  IR  ♦  1 

■300  L!  =  LI  +  < BS  -  2)  #  .25  *  51  :SI  =  SI  /  2.0 

310  IF  EXO)  -  LX(  1 )  <  CV  OR  EXO)  -  EX<5>  <  PU  GOTO  1000 

215  IF  IR  *  SN  GOTO  1000 

320  GOTO  700 

1000  C  -  LI  ♦  SI  /  2 

1100  FOR  I  =  1  TO  N 

1110  A  =  D(l.I)  *  D( 1 , I ) :B  =  LOG  <0<2,I)  -  C) 

1130  A1  =  Al  +  A:A2  =  A2  +  A  *  A:B1  =  Bl  ♦  B:B2  =  B2  ♦  8  *  B:AB  -  AB  +  A  * 

B 

1 1 40  NEXT  I 

; 150  SX  =  A2  -  <A1  *  Al)  /  N 

1 160  SY  •=  B2  -  (Bl  #  Bl)  /  N 

1170  SP  *  AB  -  <<A1  *  Bl)  /  N) 

: ;S0  Al  =  A!  /  N j Bl  =  Bl  /  N 

. .90  SL  *  Bl  -  (SP  /  SX)  *  Al 

.  300  SL  =  EXP  tSL) 

.  -11 0  EX  =  SP  /  SX 

.215  PRINT  ‘NUMBER  OF  ITERATIONS3” ; IR  -  1:  PRINT 
1220  PRINT  :  PRINT  ‘ASSYMPTOTE=“ : C 
.230  PRINT  ‘SLOPE  =  “ ; SL :  PRINT  “EXPONENT  =  •' : EX 
1235  R2  =  (SP  *  SP)  /  (SX  *  SY) 

1240  PRINT  :  PRINT  :  PRINT  “  R  SQUARED  3  -  ;R2 

.245  PRINT  :  PRINT  “EQUATION"  s  PRINT  ‘  "?  INT  (C  *  1000)  /  1000:“  +  INT 

(SL  #  1000)  /  1000;"  *  EXP(“;  INT  (EX  *  1000)  /  1000s*  *  X“2  >‘s  PRINT 

1 250  PRINT  :  INPUT  "HIT  RETURN  FOR  PLOT  OF  DATA  AND  FUNC‘;Q* 

1260  DEF  FN  RG(WW)  =  C  ♦  SL  *  EXP  (EX  *  WU  »  l«JW> 

1270  T7  =  270:05  =  150:01  ~  1 

1230  LX  =  99999 :LY  =  99999 :HX  =  -  99999 :HY  =  -  99999 

1290  FOR  I  =  1  TO  N 
i 310  IF  D(1,I)  >  HX  THEN  HX  =  D(l,l) 

1320  IF  D(1,I)  <  LX  THEN  LX  =  D(1,I) 

1330  IF  D< 2 , 1 )  <  LY  THEN  LY  =  0(2,1) 

1340  IF  D(2.I)  >  HY  THEN  HY  =  0(2,1) 

1350  IF  FN  RG( D( 1 , I ) )  >  HY  THEN  HY  =  FN  RG(D(1,I)) 

1360  IF  FN  RG(D(1,J>)  <  LY  THEN  LY  =  FN  RG(D(1,I)) 

1370  NEXT  I 

1380  LX  =  LX  -  0.1  *  (HX  -  LX) 

1390  HX  =  HX  ♦  0.1  *  (HX  -  LX) 

1400  LY  =  LY  -  0.1  *  (HY  -  LY) 

1410  HY  =  HY  *  0.1  *  (HY  -  LY) 

1420  HSR  :  HCQL0P=  3:  HPLOT  0.0  TO  0,150  TO  270,150  TO  2/0,0 

1430  FOR  1—1  TO  140  STEP  10 

1440  HPLOT  0,1  TO  5,1:  HPLOT  265,1  TO  270,1 

1 450  NEXT  1 

1460  FOR  1  =  10  TO  270  STEP  10 
1470  HPLOT  I ,145  TO  1,150 
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1480  NEXT  I 
1490  NX  =  270  /  <HX 


LX> :MY  =  150  /  (HY  -  LY) 


1500 

1510 

1520 

1530 

1540 

1550 


FOR  I  =  1  TO  N 

HPLOT  <D< 1 , I )  -  LX)  *  NX, 150  -  <D< 
NEXT  I 

FOR  I  =  25  TO  250 

HPLOT  I  -  01,05  -  <  FN  RG<  < I  -  01) 
(  FN  RG( I  /  NX  ♦  LX)  -  LY)  *  NY 
NEXT  I 


.1)  -  LY)  »  NY 


/  NX  ♦  LX)  -  LY)  *  NY  TO  1,05  - 


1560  LX  =  I NT  (LX  *  100)  /  100 :LY  =  INt  (LY  *  100)  /  100 :HX  =  INT  (HX  » 
100)  /  1 00 :HY  =  INT  (HY  *  100)  /  1 00 
1570  VTAB  21:  PRINT  “FILE=“:DSS:  PRINT  <LOU  X  VALUE=";LX;  TAB(  21);"HIGH 
X  UALtiE=“  ;HX:  PRINT  “LOW  Y  UALUE=‘;LY{  TA8(  21 )  j “HIGH  Y  VALUE=“;HY 


1 580 

1590 

10000 


INPUT 
;  END 
TEXT 
FOR 


“HIT  RETURN  TO  CONTINUE,  'E'  TO  END“;QW*:  IF  QW*  ■  *E“  THEN  TEXT 

, GOTO  1220  I 

=  1  TO  N 


10860  A  «  D( 1 , I )  *  0(1 ,1) :5  =  LOG  (D(2,I)  -  C) 

10870  A1  =  A1  +  A :A2  =  A2  +  A  *  A:B1  =  B1  +  B:B2  =  B2  +  B  *  B:AB  =  AB  +  A 
*  B 

10880  NEXT  I 

.10890  SX  =  A2  -  (A1  *  Al)  /  N 

10900  SY  =  B2  -  (B1  *  Bl)  /  N 

: 1 000  SP  =  AB  -  ((Al  *  Bl)  /  N) 

.1500  R2  =  (SP  *  SP)  /  (SX  *  SY) 

12000  Al  =  0 :A2  =  0 : Bl  =  0:B2  =  0:AB  = 

12020  RETURN 
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Appendix  E 

COMPUTER  PROGRAM  USED  FOR 
INVERSE  SQUARED  EXPONENTIAL  REGRESSION 
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5  LQMEM:  16335 
10  D*  »  f HR*  (4) 

20  PRINT  "ENTER  NAME  OP  DATA  BASE  FOR  ANALYSIS" :  PRINT  *  OR  'RETURN'  IF 
DATA  ,-RE  TO  BE  PRINT  *  ENTERED  MANUALLY* 

30  INPUT  DSC:  IF  LEN  <DS*)  <  1  GOTO  500 
35  ONERR  GOTO  <s0 

40  PRINT  D*:"0PEN  “  ;DS*  j  PRINT  D«s*READ  "jOS*:  INPUT  ND:  POKE  216. 0:N  * 
ND  /  2:FL  =  1 :  GOTO  500 
60  IF  PEEK  < 222 >  <  >  5  THEN  STOP 

70  POKE  216,0 

80  PRINT  :  PRINT  "THIS  DATA  SET  DOES  NOT  CURRENTLY  EXIST":  PRINT  *  ENTER 
DATA  TO  CREATE  IT  OR  HIT":  PRINT  *  'RETURN'  TO  EXIT  THE  PROGRAM* 

90  I  «  C:  DIM  Af <500) 

100  PRINT 

110  PRINT  *  TYPE  '*♦'  TO  QUIT" 
i 20  PRINT  "  TYPE  'SB'  TO  BACKUP* 

125  PRINT  "IND  VARS  ARE  ODD  ENTRIES":  PRINT  "DEP  VARS  ARE  EVEN  ENTRIES* 

130  I  =  I  +  1 

140  PRINT  "INPUT  #" s I 

150  INPUT  A*<I> 

155  IF  I  »  1  AND  A*<I>  =  *"  THEN  PRINT  D* t “DELETE  ";DS*:  STOP 
160  IF  A$< I)  =  “*B“  THEN  1=1-1:  GOTO  140 
l 70  IF  A*<I)  =  “*$“  GOTO  200 
ISO  GOTO  100 
190  PRINT 

200  PRINT  DT ; "OPEN  ";DS* 

210  PRINT  DJ : "WRITE  ";DS$ 

220  PRINT  I  -  1 

230  FOR  J  =  1  TO  I  -  1 

240  PRINT  A*<J>  . - - 


250  NEXT  J  - 

260  PRINT  D$; "CLOSE  *:DS*  —  '  • 

270  GOTO  40 

500  H=-  9999:1  =  9999 
•510  DIM  D<  2 . 500 > 

520  IF  FL  =  0  THEN  INPUT  "NUMBER  OF  DATA  PAIRS" ;N 
530  FOR  I  =  1  TO  N 

540  IF  FL  =  0  THEN  PRINT  "  DATA  PAIR  < IND  VAR 

550  INPUT  0<1.I), 0<2,I) 

560  IF  D 2 , 1 )  >  H  THEN  H  =  U<2,I) 

570  IF  D. ?,I)  <  L  THEN  L  =  D<2,I> 

530  NEXT  ‘ 

585  PRINT  DS ; “CLOSE" :  HOME 
600  DIM  EX<5) :CV  =  .001 :SN  =  25 
610  IR  =  1 

620  LI  =  H : H I  =  2  «  H  -  L 
630  £X( 1 )  =  0 
640  £X<5)  =  o 


DEP  VAR) 


645  SI  =  HI  -  LI 


650  C  =  LI  ♦  .5  «  SI 

560  GOSUB  10000 :E/< 3)  «  R2 

700  C  =  LI  ♦  .25  *  SI:  GOSUB  I0000:EX<2)  »  R2 

710  C  =  LI  ♦  .75  *  SI:  GCSUE  1 0000 :ZX( 4)  a  R2 

720  BV  =  -  999 
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730  FOR  !  -  2  TO  4 

740  IF  EX(I)  >  BD  THEN  BS  =  I iBV  ■  Ex(I> 

750  NEXT  I 

760  AX  =  EX(  65  -  1 )  :AY  ■  EX(BS):A2  *  EX(BS  ♦  1) 

"70  EX(1)  *  aX  :EX( 3)  «  AY:EX(5)  *  A2 

IR  -  IR  ♦  i 

900  LI  »  LI  ♦  (BS  -  2)  «  .23  #  SI :SI  ■  SI  /  2.0 

310  IF  EX( 3)  -  EX< 1 )  <  CV  OR  EX(3>  -  EX(5>  <  CV  GOTO  1000 

315  IF  IR  *  SN  GOTO  1000 

820  GOTO  700 

1000  C  -  LI  ♦  SI  /  2 

1100  FOR  I  =  1  TO  N 

1110  A  =  0(1,1'  *  D(  1  , 1 )  :B  -  LOG  <C  -  D(2,Ii) 

1130  A1  *  A1  ♦  A:A2  *  A2  ♦  A  *  AsBl  =*  B1  ♦  B:B2  *  82  ♦  B  *  B:AB  -  AB  ♦  A  * 
B 

!  140  NEXT  I 

: 150  SX  =  A2  -  (Al  *  Al )  /  N 

160  SY  *  B2  -  <B1  #  Bl)  /  N 

170  SP  »  AB  -  <(A1  *  Bl)  /  N> 

1 180  Al  =»  Ai  /  N:B1  »  Bl  /  N 

: 1?0  SL  =  Bl  -  <SP  /  SX)  *  Al 

.200  SL  =  EXP  ( SL) 

210  EX  =  SP  /  SX 

215  PRINT  "NUMBER  OF  ITERATI ONS=“ ; I R  -  1:  PRINT 
■220  PRINT  :  PRINT  "ASSYMPTOTE=“ ;C 
.230  PRINT  “SLOPE  =  ";  -  SL:  PRINT  *  EXPONENT  =  “jEX 
.235  R2  =  (SP  *  SP)  /  (SX  *  SY) 

..40  PRINT  :  PRINT  :  PRINT  “  R  SQUARED  =  ";R2 

.  245  PRINT  :  PRINT  "EQUATION-:  PRINT  “  “;  I  ITT  (C  *  1000)  /  1000  ;“  -  "{  INT 

(SL  *  1000)  /  1000;“  *  EXP( “ ;  INT  (EX  *  1000)  /  1000;“  *  X'2)“»  PRINT 

1250  PRINT  :  INPUT  "HIT  RETURN  FOR  PLOT  OF  DATA  AND  FUNC“;Q$ 

1260  DEF  FN  RG(WW)  =  C  -  SL  *  EXP  (EX  *  WW  *  WW> 

1270  T7  =  270:05  =  1 50 : Oi  =  2  -  . . 

1280  LX  =  9999? :LY  =  99999 \ HX  =  -  9999? :HY  =  -  99999 

1290  FOR  I  =  1  TO  N 

1310  IF  D< 1 , I )  >  HX  THEN  HX  =  D< 1,1) 

1320  IF  0(1,1)  <  LX  THEN  LX  =  D( 1 , I ) 

: 330  IF  D < 2 , 1 )  <  LY  THEN  LY  =  D(2,I) 

1340  IF  0(2,1)  >  HY  THEN  HY  =  D(2,I) 

1350  IF  FN  RG(D(  1,1))  )  HY  THEN  HY  =  FN  RG(D(1,D) 

1360  IF  FN  RG(D(1,I))  <  LY  THEN  LY  =  FN  RG(D< 1,1)) 

1370  NEXT  I 

1380  LX  =  LX  -  0.1  *  (HX  -  LX) 

1390  HX  =  HX  ♦  0.1  *  (HX  -  LX) 

1400  LY  *  LY  -  0.1  »  (HY  -  LY) 

1410  HY  *  HY  ♦  0.1  #  (HY  -  LY) 

1420  HGR  :  HCOLOR=  3:  HPLOT  0,0  TO  0.150  TO  270,150  TO  270,0 

1430  FOR  I  =  .  TO  140  STEP  10 

1440  HPLOT  0,1  TO  5,1:  HPLOT  265,1  TO  270,1 

1450  NEXT  I 

1460  FOR  I  =  10  TO  270  STEP  10 
1470  HPLOT  1,145  TO  1,150 
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1480  NEXT  I 

.490  MX  *  270  /  \HX  -  LX):MY  »  150  /  (HY  -  LY> 

;300  FOR  I  =  1  TO  N 

.310  HPLOT  •; 0 <  1 . 1  >  -  LX)  •  MX, 130  -  <D(2,I)  -  LY)  *  MY 
20  NEXT  I 

30  FOR  1  *  25  TO  250 
1 *40  HPLOT  I  -  01,03  -  <  FN  RG< ( I  -  01)  /  MX  ♦  LX)  -  LY)  •  MY  TO  1,03  - 
(  FN  RP( 1  /  MX  ♦  LX)  -  LY)  *  MY 
! 550  NEXT  I 

1530  LX  *  I NT  (LX  #  100)  /  100 iLY  *  1NT  <LY  *  100)  /  100 :HX  ■  1NT  (HX  ♦ 
100)  /  100 :HY  -  INT  <HY  »  100)  /  100 
:  570  UTAB  21i  PRINT  “FILE-*  sOSfj  PRINT  "LOU  X  UAI  UE«- sLX j  TAB(  21)s*HIGH 
X  VALUr-'jHXj  PRINT  “LOW  Y  UALUE»*;LY{  TAB<  21>t*HIGH  Y  VALUE-**  SHY 

•  380  INPUT  “HIT  RETURN  TO  CONTINUE.  'E'  TO  END'jQW*:  IF  OUt  ■  •£•  THEN  TEXT 

:  END 

. 390  TEXT  :  GOTO  1220 
. J000  FOR  I  «  1  TO  N 

•  (360  A  =  D(l.l)  *  0<  1 , 1 )  :B  =  LOG  <C  -  D(2.D) 

;v370  Al  =*  Al  ♦  A:A2  *  A2  ♦  A  *  A:BI  *  81  ♦  B:B2  *  B2  ♦  8  *  B :AB  =>  AB  *  A 
•  B 

..■330  NEXT  I 

390  SX  *  A2  -  (A1  »  Al)  /  N 

:  .'900  SY  ■  B2  -  <B1  *  Bl)  /  N 

. 10QQ  SP  =  AB  -  ((Al  *  Bl)  /  N) 

1500  R2  =  (SP  *  SP)  /  (SX  *  SY) 

12000  Al  =  0  :A2  =  0 : Bl  =*  0 : B2  =  0  :A8  =  0 
i 2020  RETURN 
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1  Appendix  F 

COMPUTER  PROGRAM  USED  FOR 
POLYNOMIAL  REGRESSION 


3  LOMEM:  16383 
10  D*  »  CHR*  < 4) 

23  PRINT  ‘ENTER  NAME  OF  DATA  EASE  FOR  ANALYSIS*:  PRINT  *  OR  'RETURN'  IF 
DATA  ARE  TO  BE  * :  PRINT  •  ENTERED  MANUALLY* 

30  INPUT  DS*:  IF  LEN  (OS*)  <  I  GOTO  500 
25  ONERR  GOTO  60 

•>0  PRINT  D*:‘0PEN  *;DS*:  PRINT  D*;*READ  *;DS*:  INPUT  NO:  POKE  21  <S,0 :N  * 
ND  /  2:FL  -  1:  GOTO  500 
sO  IF  PEEK  (222)  <  >  3  THEN  STOP 

70  POKE  216,0 

SO  PRINT  :  PRINT  ‘THIS  DATA  SET  DOES  NOT  CURRENTLY  EXIST*:  PRINT  *  ENTER 
DATA  TO  CREATE  IT  OR  HIT*:  PRINT  *  'RETURN'  TO  EXIT  THE  PROGRAM' 

’0  I  »  0:  DIM  A* <500) 

100  PRINT 

;10  PRINT  *  TYPE  '**'  TO  QUIT* 

,20  PRINT  *  r YPE  '$B'  TO  BACKUP* 

23  PRINT  ‘ JND  VARS  ARE  ODD  ENTRIES*:  PRINT  *DEP  VARS  ARE  EVEN  ENTRIES* 
:30  I  «  I  ♦  1 
-*0  PRINT  ‘INPUT  #‘:I 
.50  INPUT  A*< I ) 

.55  IP  I  -  1  AND  A*(  I )  -  “  THE?'!  PRINT  D*t  “DELETE  -  jDS* s  STOP 
.60  If  Alii)  *  "*B‘  THEN  1*1-1:  GOTO  140 
.70  IF  A*( I )  *  ****  GOTO  200 

:ao  goto  ioo 

.  50  PRINT 

-0C  PRINT  D*»*OPEN  ‘  ;DS* 

210  PRINT  D*: ‘WRITE  *;0S* 

.20  PRINT  I  -  1 

230  FOR  J  -  1  TO  I  -  1 

-40  PRINT  A*(J) 

250  NEXT  J 

260  PRINT  D*;*:LOSE  ‘:DS* 

270  GOTO  40 
500  DIM  D(2.300) 

510  PRINT  :D*  *  CHR*  <4) 

520  IF  FL  *  0  THEN  INPUT  •#  DATA  GROUPS’ ;N 
530  FOR  I  *  1  TO  N 

540  IF  FL  *  0  THEN  PRINT  ‘INPUT  DATA  GROUP  *;lj*  ( 1ND  VAR,  DEP  VAR)* 

550  INPUT  A,C:B  *  A  *  A:D<1,I)  *  A:D(2,I)  *  C 
560  X  =  X  ♦  A:Y  *  Y  ♦  8:2  *  2  ♦  C 

570  X2  *  X2  ♦  A  *  A:Y2  »  Y2  ♦  8  *  B:22  *  22  ♦  C  *  C 

580  XY  *  XY  ♦  A  #  B:XZ  *  XZ  ♦  A  #  C:Y2  *  Y2  ♦  B  *  C 

5?0  NEXT  1 

*00  PRINT  D*: ‘CLOSE*:  HOME 

410DT=N»X2*Y2+X»KY*Y#2-Y«X2»Y-N*XY«XY-X*X* 

Y2 

620  DIM  XK3.3)  ,YM<3)  ,BM<3) 

630  YM( 1 )  *  ZiYM^Z)  *  X2:YM(3>  *  Y2 
:40  XI (I ,1)  *  X2  »  Y2  -  XY  »  XY 

:50  XI< 1 ,2)  *  -  (X  *  :2  -  XY  *  i> 

560  XI(1 ,3)  *  X  *  XY  -  X2  •  Y 
*70  X I ( 2 . 2  >  *  N  *  Y2  -  Y  *  Y 
680  X! (2,3)  -  -  (N  «  <Y  -  X  *  Y) 
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690  XI<3,3)  «N»X2-X»X 
700  XI<2. 1 )  »  XI(1 ,2) 

710  XI <3. 1 )  ■  XI ( 1 ,3) 

720  XI<3,2)  =»  XI(2,3> 

730  FOR  I  *  1  TO  3:  FOR  J  =  1  TO  3tXI(I.J>  a  XKI.J)  /  DT:  NEXT  Js  NEXT 


740  FOR  I  =  1  TO  3 
750  FOR  J  -  1  TO  3:8M(I ) 


BM<I>  ♦  XI (I, J)  *  YM<  J) :  NEXT  J 


REGRESSION  ANALYSIS" 


<Z  *  Z) 


76 0  NEXT  I  / 

770  FOR  I  «  1  TO  3 : 2 H  -  ZH  ♦  BM(I)  *  YM(I) s  NEXT  I 
780  R  -  I  -  <Z2  -  ZH)  /  <22  -  <Z  *  Z)  /  N) 

790  HOME 

800  VTAB  5s  PRINT  *  REGRESSION  ANALYSIS" 

310  PRINT 

820  FOR  I  -  1  TO  3 

330  PRINT  "  B( " ;  I  -  1 ;BM( I) 

340  NEXT  I 

350  PRINT  s  PRINT  "R  SQUARED  *  *;R 
360  5Y  *  R  *  <Z2  -  <Z  *  Z)  /  N) 

370  5E  *  Z2  -  ZH 

380  PRINT  i  PRINT  *  AN OVA  r 

390  PRINT  "SS  DUE  TO  Y=*";SY 

>00  PRINT  "MS  DUE  TO  Y«*;SY  /  2 

>10  PRINT  "SS  DUE  TO  ERROR=";SE 

520  PRINT  "MS  DUE  TO  ERROR=*“:SE  /  (N  -  3> 

>30  PRINT  :  PRINT  4  F< 2,";N  -  3;")=“;  INT  (<(SY  /  2)  /  <SE  /  -.N  -  3))>  * 

560)  /  100 

>32  PRINT  :  PRINT  "EQUATION* 

>34  PRINT  I NT  <BM< 1 >  *  1000)  /  1000;"  ♦  JNT  <BM<2)  *  1000)  /  1000;" 

*  X  ♦  "  I  INT  <  8M<  3)  *  1000)  /  1000s"  *  X*2" 

>40  INPUT  "HIT  RETURN  FOR  PLOT'sG* 

>50  DEF  FN  RGOJU)  ■  8M< 1 )  ♦  BM<2>  *  UW  ♦  BM<3)  #  UU  *  UU 
>60  T7  ■  270 s05  -  150:01  =  1 

97 0  LX  »  99999 :LY  «  9999®: HX  *  -  99999 :HY  *  -  99999 

>79  FOR  1  *  1  TO  N 

990  PRINT  0 <  l ,  I  >  ,D< 2,1),  FN  RG<D<1,D) 

1000  IF  D< 1 , 1 )  >  HX  THEN  HX  =  0<1,1) 

1010  IF  D<1,1)  (  LX  THEN  LX  «  0< 1 , 1 > 

1020  IF  D(2, I )  <  LY  THEN  LY  »  D<2,!> 

1030  IF  D<2. 1 >  )  HY  THEN  HY  «  D<2,1) 


1040  IF  FN  RG<D<1.D)  >  HY  THEN  HY 
1050  IF  FN  RG<D<1,I>>  <  LY  THO-I  LY 


FN  RG(0( 1 , 1 >) 
FN  RG(D< 1 , 1 > > 


1060  NEXT  I 
1070  LX  •  LX 
1080  HX  «  HX 
1090  LY  -  LY 
1100  HY  -  HY 


LX  -  0.1  •  (HX  -  LX) 
HX  ♦  0.1  •  (KX  -  LX) 
LY  -  0.1  *  (HY  -  LY) 
HY  ♦  0.1  *  (HY  -  LY) 


1110  HGR  s  HCOLCRa  3:  HPLOT  0,0  TO  0,150  TO  270,150  TO  270,0 

1120  FOR  I  »  I  TO  140  STEP  10 

1130  HPLOT  0,1  TO  5.1:  HPLOT  265,1  TO  270.1 

. 1 40  NEXT  I 

1130  FOR  1  -  10  TQ  270  STEP  10 
. 160  HPLOT  1,143  TO  1,130 
1170  NEXT  1 


1180  MX  3  270  /  <HX  -  LX)  :MY  =*  150  /  <HY  -  LY) 

1190  FOR  1  ■  1  TO  N 

1200  HPLOT  < D< 1,1)  -  LX)  *  MX, 150  -  <D<2,I>  -  LY)  *  MY 

1210  NEXT  I 

1220  FOR  1  *  20  TO  250 

1230  HPlOT  1  -  01.05  -  <  FN  RG<(I  -  01)  /  MX  ♦  LX)  -  LY)  *  MY  TO  1,05  - 
<  FN  RG(I  /  MX  ♦  LX)  -  LY)  *  MY 
1240  NEXT  I 

1250  LX  »  INT  <LX  *  100)  /  100 : LY  *  INT  <LY  *  100)  /  1 0 0 : HX  ■  INT  (HX  * 
100)  /  1 0 0 : HY  »  INT  <HY  *  100)  /  100 
1255  VTA8  21:  PRINT  “FILE»*;DS*:  PRINT  *L0U  X  VALUE3* ;LX;  TA8(  21)  THIGH 
X  VALUE3* : HX :  PRINT  *LOW  Y  VALUE=*jLY;  TAB(  21){“HIGH  Y  VALUE3", ‘HY 
1250  INPUT  "HIT  RETURN  TO  CONTINUE,  'E'  TO  END*  jQLi$: 

1270  TEXT 

21240  INPUT  "HIT  RETURN  TO  CONTINUE,  'E'  TO  END* ;QW* :  IF  QWS  <  >  “E*  THEN 

TEXT  :  GOTO  800 


4 

$ 

i 

4 
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Appendix  G 

COMPUTER  PROGRAM  USED  FOR 
MULTIPLE  REGRESSION 


^  •  L 
: 

^  K 


v  1  r  * 


a  b 

J;  y: 

£ 

I  f 

: 


$  :■{ 

W  Lk 

» 


v\  ■ 

I.-. 


3  LGriEMi  16385 
!0  M  »  CHR*  (4) 

'0  PRINT  ‘ENTER  NAME  OF  DATA  BASE  FOR  ANALYSIS*  I  PRINT  *  OR  /RET*.""T'  IF 
DATA  ARE  TO  BE  ‘ :  PRINT  "  ENTERED  MANUALLY* 

30  INPUT  OSS :  IF  LEN  <DS»>  <  1  GOTO  500 
35  ONERR  GOTO  60 

40  PRINT  Di 5 "OPEN  * ;DS* t  PRINT  D$ ; "READ  *;DS*i  INPUT  ND:  POKE  216, 0:N  » 

ND  /  3.-FL  -  1:  GOTO  500 
40  IF  PEEK  <222)  <  >  5  THEN  STOP 

?0  POKE  216,0 

30  PRINT  s  PRINT  "THIS  DATA  SET  DOES  NOT  CURRENTLY  EXIST*!  PRINT  *  ENTER 
DATA  TO  CREATE  IT  OR  HIT*!  PRINT  *  'RETURN'  TO  EXIT  THE  FROGRAM" 

:0  I  *  0 !  DIM  Ai( 500 ) 

;t)u  PRINT 

PRINT  “  TYPE  '**'  TO  QUIT" 

:'2j  PRINT  "  TYPE  '$B'  TO  BACKUP" 

..5  PRINT  "ORDER-IND  UAR  1,  IND  VAR  2,  DEP  VAR" 

-31  =  1  +  1 
-0  PRINT  "INPUT  #"{I 
;f0  INPUT  Ai(  I ) 

:zz  IF  I  =  1  AND  Aid)  =  *"  THEM  PRINT  D$; "DELETE  “;DSii  STOP 
160  IF  AS < I )  =  “«B*  THEN  1  =  l  -  Is  GOTO  140 
1-0  IF  A»<I)  =  “i$"  GOTO  200 
i 30  GOTO  100 
190  PRINT 

200  PRINT  Di j " OPEN  - ;OSS 
210  PRINT  Di; "WRITE  “;DSi 
220  PRINT  I  -  1 
230  FOR  J  =  1  TO  I  -  1 
240  PRINT  Ai(J) 

250  NEXT  J 

260  PRINT  Di; "CLOSE  ";DSi 

270  GOTO  40 

500  DIM  D<2,500) 

510  PRINT  :Di  =  CHRi  <4) 

520  IF  FL  =  0  THEN  PRINT  "INPUT  DATA  GROUP  ";I 

530  FOR  I  =  1  TO  N 

540  PRINT  "INPUT  DATA  GROUP  ";l! 

550  INPUT  A,B,C 

560  X  =  X  +  A:Y  =  Y  +  G : 2  =  2  ♦  C 

570  X2  =  X2  ♦  A  *  A :Y?  =  Y2  +  B  *  B : Z2  =  22  ♦  C  *  C 

580  XY  =  XY  ♦  A  »  B:XZ  =  XZ  +  A  #  CsYZ  =  YZ  ♦  B  *  C 

590  NEXT  I 

600  PRINT  Di; "CLOSE" 

6100T=N*X2*Y2+X*XY*Y#2-Y#X2*Y-N*XY*XY-X*X* 

Y2 

420  DIM  XI<3,3) ,YM<3> ,BM<3) 

6  30  YM< 1 )  =  Z :YM< 2)  =  XZ:YM<3)  =  YZ 
640  XI < 1,1)  »  X2  *  Y2  -  XY  *  XY 
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o50  XI (1.2)  »  -  (X  «  Y2  -  XV  #  Y) 

06O  XI (1,3)  -  X  *  XY  -  X2  *  1 
s70  XI (2,2)  *  N  #  Y2  -  Y  *  Y 
380  XI (2,3)  *  -  (N  «  XY  -  X  *  Y) 

A90  XI (3.3)  «N«X2-X#X 
700  X I  ( 2 , 1 )  *  XKl  ,2) 

710  Xl(3,i;  «  XKl  ,3) 

720  XI(3.2)  »  XI (2,3) 

730  FOR  I  »  1  TO  3:  FOR  J  »  1  TO  3:XI(1,J)  *  XI(1,J)  /  DT:  NEXT  J:  NEXT 
I 

7*10  FOR  I  *  1  TO  3 

750  FOR  J  -  1  TO  3:BM(I>  *  EM(1)  ♦  XI(I,J)  #  YM(J):  NEXT  J 

760  NEXT  I 

770  FOR  1  *  1  TO  3:2H .«  ZH  ♦  BM(I>  *  YM(I)s  NEXT  1 

780  R  =  1  -  ( Z2  -  ZH)  /  ( Z 2  -  (Z  *  Z)  /  N) 

790  HOME 

500  VTA 8  5:  PRINT  *  REGRESSION  ANALYSIS' 

91 0  PRINT 

320  FOR  I  =  1  TO  3 

<3C  PRINT  •  B < " ; 1  -  1 }*)*" ;BM(I) 

340  NEXT  I 

350  PRINT  :  PRINT  ”R  SQUARED  =  ";R 
360  SY  =  R  *  (Z2  -  <Z  *  Z)  /  N) 


Km 


g 

E 


v. 


370  SE  =  Z2  -  ZH 
380  PRINT  :  PRINT 
390  PRINT 
>00  PRINT 
>10  PRINT 
•'20  PRINT 
930  PRINT 


ANOVA  ‘ 

SS  DUE  TO  Y=“ ;SY 
M3  DUE  TO  Y=" ;SY  /  2 
S3  DUE  TO  ERR0R=-iSE 
MS  DUE  TO  ERROR=“ ;SE  / 
PRINT  "  F( 2 , “ ;N  -  3 j 1 


<N  -  3) 

)=“ ;  INT  (((SY  /  2)  /  (SE  /  (N  -  3)))  * 

560)  /  100 

932  PRINT  :  PRINT  'EQUATION* 

034  PRINT  INT  ( BM( 1 )  *  1000)  /  1000;”  ♦  INT  (BM<2)  *  1000)  /  1000;“* 
X( 1 ) )  ♦  *;  INT  (BM(3)  *  1000)  /  1 000  ;  **X( 2) ) " 

940  END 

950  DEF  FN  RG(WW)  =  8M(1)  +  BM(2)  *  WU  +  BM<3)  *  WW  *  WW 
960  T7  =  270 sJ5  =  150:01  =  1 
970  LX  =  99999 :LY  =  99999:HX  = 


99999 :HY  =  -  99999 


980 

990 

1000 

1010 

1020 


FOR  I  =  1  TO  N 

PRINT  D( 1 , 1 ) ,D(2, 1 ) ,  FN  RG(D(1,I)) 

IF  D(1  ,1)  >  HX  THEN  HX  =  D(1 ,1) 

IF  0(1,1)  <  LX  THEN  LX  =  D(1  ,1) 

IF  D< 2, 1 )  <  LY  THEN  LY  =  D(2,I) 


r\ 

1030 

IF  0(2,1)  >  Hi  THEN  HY  =  D(2,I) 

1040 

IF  FN  RG(D( 1 , I ) )  >  HY  THEN  AY  = 

FN 

RG(D(1 

,D) 

V* 

1050 

IF  FN  RG(D(1 ,I>)  <  LY  THEN  LY  = 

FN 

RG(  D(  1 

,D) 

*  » 

1060 

NEXT  I 

1 

1070 

LX  =  LX  -  0.1  *  (HX  -  LX) 

1080 

HX  =  HX  +  0.1  *  (HX  -  LX) 

1  , 

1090 

LY  =  LY  -  0.1  *  (HY  -  LY) 

! 

1100 

HY  =  HY  ♦  0.1  #  (HY  -  LY) 

1110 

HGR  :  HCOLOR=  3.  HPLOT  0,C  TO  0, 

150  ' 

TO  270, 

150  TO 

Vv 

1120 

FOR  I  =  1  TO  140  STEP  10 

N— 7  3 


£s 

i J 


i 


1130  HPLOT  0,1  TO  5,1 i  HPLOT  245,1  TO  270.1 
1140  NEXT  I 

1150  FOR  I  »  10  TO  270  STEP  10 
1140  HPLOT  1,145  TO  1,150 
1170  NEXT  1 

1180  MX  *  270  /  <HX  -  LX) :MY  =  150  /  < HY  -  LY) 

1190  ■ FOR  I  -  1  TO  N 

1200  HPLOT  <D< 1 , 1 )  -  LX)  *  MX, 150  -  <D<2,I>  -  LY)  *  MY 

1210  NEXT  I 

1220  FOR  I  ■  20  TO  250 

1230  HPLOT  I  -  01,05  -  <  FN  RG<  < 1  -  01 )  /  MX  ♦  LX)  -  LY)  *  MY  TO  1,05  - 
<  FN  RGCI  /  MX  ♦  LX)  -  LY)  *  MY 
l 240  NEXT  I 

1250  MTAB  21:  PRINT  “LX=“:LX;“  LY=  * ; LY :  PRINT  "MX="5MX;*  MY=*  ;MY 
1240  INPUT  “HIT  RETURN  TO  CONTINUE" ;QW* 

1 270  TEXT 


B 

£ 

I 


a 

a* 


rvj 


£ 
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Standard  M3FAX&  Terminology 


AIR  DEFENSE  SYSTEM 

A  ccwponent  of  Air  Defense  which  ir.cluuM 
equipment  and  operators  and  fear  which 
technical  and  tactical  training  arc  required. 
Examples  ere  IHAWK  and  the  AN/TSQ-73. 

AIR  DEFENSE  SYSTEM 
MODULE 

Models  of  operator  actions  and  equipment 
characteristics  for  Air  Defease  Systems  in 
the  MOPADS  software.  These  models  are  pre¬ 
pared  with  the  SAINT  simulation  language. 

Air  Defense  System  Modules  include  the 

SAINT  model  and  all  data  needed  to  com¬ 
pletely  define  task  element  tines,  task 
sequencing  requirements,  and  human  factors 
Influences. 

AIR  SCENARIO 

A  spatial  and  temporal  record  of  aerial 
activities  and  characteristics  of  an  air 
defense  battle.  The  Air  Scenario  includes 
aircraft  tracks,  safe  corridors,  ECM,  and 
other  aircraft  and  airspace  data.  See 
also  Tactical  Scenario. 

BRANCHING 

A  term  used  in  the  SAINT  simulation  lang¬ 
uage  to  mean  the  process  by  which  TASK  nodes 
are  sequenced.  At  the  completion  of  the 
simulated  activity  at  a  TASK  node,  the 
Branching  from  that  node  determines  which 
TASK  nodes  will  be  simulated  next. 

DATA  BASE  CONTROL 
SYSTEM 

That  part  of  the  MOPADS  software  which 
performs  all  direct  communication  with  the 
MOPADS  Data  Base.  All  information  transfer 
to  and  from  the  data  base  is  performed  by 
invoking  the  subprograms  which  make  up  the 
Data  Base  Control  System. 

DATA  SOURCE 

SPECIALIST 

A  specialist  in  obtaining  and  interpreting 
Army  documentation  and  other  data  needed  to 
prepare  Ai1*  Defense  System  Modules. 

ENVIRONMEflTAL 
STATE  VARIABLE 


ENVIRONMENTAL 
STATE  VECTOR 


MODERATOR  FUNCTION 


An  element  of  an  Environmental  State 
Vector. 


An  array  of  values  representing  conditions 
or  characteristics  that  may  affect  more 
than  one  operator.  [Elements  of  Environmen¬ 
tal  State  Vectors  may  change  dynamically 
during  a  MOPADS  simulation  to  represent 
changes  in  the  environment  conditions. 


A  mathematical/logical  relationship  which 
alters  the  nominal  time  to  perform  an  opera¬ 
tor  activity  (usually  a  Task  Element).  The 
nominal  time  is  changed  to  represent  the 
operator's  capability  to  perform  the 
activity  based  on  the  Operator's  State 
Vector.  ! 


MOPADS  DATA  BASE  A  computerized  data  base  designed  specifi¬ 

cally  to  support  the  MOPADS  software.  The 
MOPADS  Data  Base  contains  Simulation  Data 
Set(s).  It  communicates  interactively  with 
MOPADS  Users  during  pre-  and  post-run  data 
specification  and  dynamically  with  the  SAINT 
software  during  simulation. 


MOPADS 

MODELER  # 

An  analyst  who  will  develop  Air  Defense 
System  Modules  and  modify/ develop  the 

MOPADS  software  system. 

MOPADS 

i 

USER  1 

An  analyst  who  will  design  and  conduc*.  simu¬ 
lation  experiments  with  the  MOPADS  so:tware. 

MSAINT 

The  variant  of  SAINT  used  in  the  MOPADS 

(MOPADS/SAINT)  system.  The  standard  version  of  SAINT  has 

been  modified  for  MOPADS  to  permit  share¬ 
able  subnetworks  and  more  sophisticated 
interrupts.  The  terms  SAIUT  and  MSAIIIT  are 
used  interchangeably  when  no  confusion  will 

result.  See  also,  SAINT. 

I 


OPERATOR  STArE 
VARIABLE 

One  element  of  an  Operator  State  Vector. 

OPERATOR  STATE 

VECTOR 

An  array  of  Tali**  representing  the  condi¬ 
tion  and  characteristics  of  an  operator  of 
an  Air  Defense  System.  Many  values  of  the 
Operator  Stats  Vector  will  change  dynamically 
during  the  course  of  a  KJPADS  simulation  to 
represent  changes  in  operator  condition. 

OPERATOR  TASK 

An  operator  activity  identified  during 
weapons  system  front-end  analyses. 

SAINT 

The  underlying  computer  simulation  j anguage 
used  to  model  Air  Defense  Systems  in  Air 
Defense  System  Modules.  SAINT  is  an  acronym 
for  Systems  Analysis  of  Integrated  Networks 
of  Tasks.  It  is  a  well  documented  language 
designed  specifically  to  represent  human 
factors  aspects  of  man /machine  systems. 

See  also  MSAINT. 

SIMULATION  DATA  SET 

The  Tactical  Scenario  plus  all  required 
simulation  initialization  and  other  experi¬ 
mental  data  needed  to  perform  a  MOPADS 
simulation. 

SIMULATION  STATE 

At  any  instant  in  time  of  a  MOPADS  simula¬ 
tion  the  Simulation  State  is  the  set  of 
values  of  all  variables  in  the  MOPADS  soft¬ 
ware  and  the  MOPADS  Data  Base. 

SYSTEM  MODULES 

See  Air  Defense  System  Modules. 

The  Air  Scenario  plus  specification  of 
critical  assets  and  the  air  defense  con¬ 
figuration  (number,  type  and  location  of 
weapons  and  the  command  and  control  system) . 


TACTICAL  SCENARIO 


TACTICAL  SCENARIO 
COMPONENT 


As  element  of  a  Tactical  Scenario,  e.g. , 
if  a  Tactical  Scenario  contains  several 
ft-73's,  each  one  is  a  Tactical  Scenario 
Component. 


TASK 


See  Operator  Task. 


TASK  ELEMENTS  Individual  operator  actions  which,  when 

grouped  appropriately,  make  up  operator 
tasks.  Task  elements  are  usually  repre¬ 
sented  by  single  SAINT  TASK  nodes  in  Air 
Offense  System  Modules. 


TASK  NODE  A  modeling  symbol  used  in  the  SAINT  Simula 

tion  language.  A  TASK  node  represents  an 
activity;  depending  upon  the  modeling  cir¬ 
cumstances,  a  TASK  node  may  represent  an 
individual  activity  such  as  a  Task  Element 
or  it  may  represent  an  aggregated  activity 
such  as  an  entire  Operator  Task. 


TASK  SEQUENCING  A  mathematlcal/logical  relationship  which 

MODERATOR  selects  the  next  Operator  Task  which  an 

FUNCTION  operator  will  perform.  The  selection  is 

oased  upon  operator  goal  seeking  character 
istics. 


I. 


INTRODUCTION 


✓ 


Operators  modeled  by  MOPADS  perform  rule-based  activities 
called  "operator  tasks."  These  are  checklist  actions  consisting  of 
a)  elemental  (at  least  as  far  as  KOPADS  is  concerned)  actions  such 
as  entering  numbers  on  a  keyboard,  and  b)  simple  decisions.  The 
operators  memorize  the  procedures  for  these  tasks. 

A  different  sort  of  activity  is  required  oy  the  operators 
when  they  decide  which  task  to  perform.  Such  decisions  by  the 
operators  represent  tactical  decisions  required  to  accomplish  their 
missions.  These  decisions  are  influenced  by  the  current  tactical 
situation,  standard  operating  procedures,  the  operator's  exper¬ 
ience,  and  the  operators  personal  motivations.  It  is  necessary  to 
model  this  "knowledge  based"  activity,  because  the  MOPADS  simulated 
operators  mu3t  sequence  these  tasks  in  such  a  way  that  they  respond 
realistically  to  the  air  battle.  This  report  describes  the  model 
used  by  MOPADS  for  operator  "task  sequencing." 

The  intended  audience  is  the  MOPADS  modeler  who  will  imple¬ 
ment  or  modify  the  task  sequencing  procedures  for  an  air  defense 
system  module.  MOPADS  users  need  to  be  familiar  with  the  material, 
but  a  less  detailed  discussion  is  contained  in  Polito  (1983a).  The 
system  module  specific  details  which  instantiate  this  procedure  for 
a  particular  system  module  are  contained  in  the  user  and  reference 
documents  for  that  module,  e.g.,  Goodin  h  Polito  (l9?3a);  Goodin  & 
Walker  ( 1983a) . 

Section  II  discusses  the  issues  in  selecting  a  task  sequencing 
methodology  for  MOPADS.  The  selected  algorithm  is  presented  in 
Section  III,  and  the  implementation  uetails  are  discussed  in 
Section  IV.  A  brief  example  of  specifying  the  data  and  preparing 
subprograms  is  given  in  Section  V. 
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II.  FACTORS  IN  SELECTING  A  TASK  SEQUENCING  METHOD 

FOR  HOPADS 

1- 0  DESIRABLE  FEATURES  OF  A  TASK  SEQUENCING  METHOD 

I 

| 

In  selecting  t  method  to  sequence  MOPADS  operator  tasks, 
several  objectives  vere  considered.  Each  of  them  is  discussed 
below. 

1.  Causal .  i  The  methodology  must  be  causal.  In  other  words, 
the  operator  should  sequence  his/her  tasks  in  response  to  the  air 
battle  and  other  pertinent  tactical  scenario  issues.  This  consider¬ 
ation  immediately  ruled  out  simple  sequencing  rules  such  as  random 

or  cyclic  sequencing. 

2.  Consistent  with  Established  Theory.  The  selected  method 
should  have  been  considered  as  a  reasonable  decision  making  model 

by  researchers.  This  consideration  lead  to  examination  of  utility 
theory  and  goal  seeking  approaches. 

3.  Computationally  Attractive.  The  method  should  not  • 
require  frequent  accomplishment  of  extensive  numerical  procedures 
such  as  curve  fitting  or  solution  of  simultaneova  equations. 

h.  Intuitively  Meaningful.  The  data  required  from  the  user 
should  be  meaningful  to  an  air  defense  specialist.  In  other  words, 
abstract  or  derived  parameters  should  not  be  required. 

5.  Economical  in  Terms  of  Data  Requirements.  The  method 
should  not  require  unusually  large  amounts  of  data. 

The  above  considerations  represent  an  ideal  profile  against 
which  candidate  methods  were  .compared. 

2- 0  CANDIDATE  TASK  SEQUENCING  METHODOLOGIES 

As  stated  above,  utility  theory  and  goal  seeking  methods  were 
considered  in  order  to  satisfy  objective  (2)  above.  Both  of  these 
methods  satisfy  the  need  for  causality,  since  the  evaluation  of  a 
particular  utility  function  or  set  of  goals  can  be  based  upon  para¬ 
meters  derived  from  the  current  state  of  the  air  battle  and  environ¬ 
ment.  Both  techniques  have  a  body  of  literature  suggesting  that 
humans  make  decisions  in  a  way  to  optimize  a  utility  function  or 
to  satisfy  goals,  j 

There  can  be  a  substantial  difference  in  the  computational 
effort  required  to  i  olement  the  two  methods.  To  use  the  utility 
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theory  approach  we  would  define  a  function  U(S)  which  maps  the 
multidimensional  vector  S  onto  the  non-negative  real  numbers.  The 
vector  S  represents  the  state  or  attributes  of  the  air  defense 
system  for  a  particular  operator.  Once  U(C)  is  known,  the  steps  in 
selecting  the  next  task  are  simple: 

i)  Evaluate  Uq *  U(S0)  for  the  current  system  state, S0 

ii)  If  alternatives  a,  b,  c,  etc.  are  available  to  the 
operator,  estimate  the  state  vectors,  Sa,  St>,  Sc» 
etc.,  that  will  result  from  selecting  each 
alternative 

iii)  Evaluate  Ua  =  U(Sa),  U-D  =  U(S-0),  etc.  and  select  the 
alternative  that  most  improves  the  operator's 
utility. 

The  difficulty  with  this  method  results  from  determination  of 
the  utility  function,  U.  To  do  this  in  its  most  general  form  would 
require  obtaining  values  of  utility  at  a  large  number  of  points  and 
developing  the  function  U(S)  from  some  curve  fitting  technique  such 
as  linear  regression.  Presumably,  su~h  data  would  be  gathered  from 
more  than  one  subject;  also  this  procedure  would  have  to  be  repeated 
for  each  operator  type  since  we  would  not  expect  a  single  utility 
function  to  apply  to  the  AH/TSQ-73  Tactical  Director  and  to  the 
IHAWK  Fire  Control  Operator.  Since  the  domain  of  S  is  a  continuum, 
the  utility  values  obtained  from  a  subject  will,  of  necessity,  be 
cardinal  values.  These  will  have  to  be  normalized  in  some  way  to 
make  the  data  from  several  subjects  comparable. 

In  addition  to  these  considerations,  it  is  desirable  to  pro¬ 
vide  at  least  the  potential  of  dynamically  altering  an  operator's 
decision  making  structure  during  the  course  of  the  simulation.  This 
would  represent  an  operator  who  changes  the  relative  importance  of 
his/her  objectives  based  upon  the  state  of  his  current  situation. 

It  can  be  argued  that  this  type  of  behavior  can  be  embodied  in  the 
utility  function  by  emanding  the  set  of  independent  variables.  While 
this  is  theoretically  true,  from  a  practical  standpoint,  a  set  of 
parameters  whose  values  change  discretely  with  changing  conditions 
is  easier  to  implement.  This  is  true  because  the  data  collection 
and  reduction  problem  discussed  above  would  be  greatly  expanded  if 
the  effects  on  goals  of  stress,  fatigue,  etc.  had  also  to  be 
estimated.  A  more  practical  approach  is  to  attempt  to  parameterize 
the  utility  functions  with  these  variables  and  to  re— compute  the 
coefficients  of  the  utility  function  as  conditions  change. 

Any  implementation  of  this  dynamic  capability  with  traditional 
utility  functions  will  involve  extensive  data  collection  and/or 
computation.  It  could  conceivably  require  re-computation  of  utility 
function  coefficients  during  the  course  of  a  simulation  which  would 
correspondingly  increase  r\m  time.  In  short,  it  would  not  be 


0-14 


economical  in  terms  of  data  requirements  or  compute! 4 anal  needs  tc 
implement  this  capability  with  utility  functions. 

Finally,  it  is  desirable  to  have  an  individual  editing  capa¬ 
bility  for  operators  that  is  analogous  to  the  editing  features  for 
other  human  factors  parameters.  Each  simulated  operator  in  a  MOPADS 
simulation  can  be  individually  edited  so  that  his/her  responses  need 
not  be  identical  to  those  for  a  nominal  operator.  A  simiia1"  capa¬ 
bility  for  task  sequencing  should  be  available,  so  the  MOPADS  user 
can  test  the  effects  of  variations  in  the  operator's  objectives.. 

In  order  to  do  this,  parameters  must  be  available  for  the 
MOPADS  user  to  edit.  These  parameters  should  have  intuitive  meaning 
to  the  user.  Therefore,  the  ability  to  alter  coefficients  in  the 
utility  function  (which  may  have  been  determined  by,  say,  linear 
regression)  is  really  not  sufficient.  On  the  other  hand,  altering 
the  data  from  which  the  utility  function  is  determined  requires  that 
the  function  coefficients  be  re-computed  and  also  may  lead  to 
unintended  effects  on  the  operators  utility  function.  In  other 
words,  it  may  be  difficult  for  the  user  to  predict  the  impact  of 
certain  changes  on  the  resulting  utility  function. 

The  other  major  alternative,  a  goal  seeking  procedure,  can  be 
implemented  in  such  a  way  so  as  to  satisfy  most  of  the  goals  in  1-0 
above.  Suppose  an  operator  has  a  set  of  (not  necessarily  indepen¬ 
dent)  goals,  G^,  G2,  G_ ,  etc.,  each  of  which  has  an  associated  goal 
state.  For  example, if 3the  goal  is  to  maximize  the  distance  of  enemy 
aircraft  to  any  protected  site,  then  the  goal  state  is  the  minimum 
distance  of  any  hostile  aircraft  to  any  protected  site.  Each  goal 
state  is  a  function  of  certain  variables  whose  values  are  known. 
There  is  a  subset  of  the  range  of  each  goal  state  in  which  the  goal 
is  satisfied.  When  the  goal  state  is  not  in  this  subset,  it  is 
to  some  degree  unsatisfied. 

The  operator  must  be  able  to  assign  .  degree-of-dissatisfac- 
tion  to  unsatisfied  goals  which  is  a  function  of  its  jgoal  state. 

He  then  identifies  his  most  dissatisfied  goal(s)  and  selects  a  task 
which  will  improve  his/her  level  of  satisfaction.  Th(e  steps  in  this 
process  are: 

x) 


ix) 


iii) 


iv) 


Evaluate  each  goal  state  G^(S^),  Gp(SQ),  G_(Sq), 
at  the  current  set  of  system  variables,  Sq. 

If  alternatives  a,  b,  c,  etc.,  are  available  to 
the  operator,  estimate  the  system  variables  which 
will  result  from  each  alternative,  S&,  S^,  Sc,etc. 

Evaluate  the  goal  states  expected  to  result  from 
each  alternative,  G]_(Sa),  G2^b^  ’ 

Select  the  alternative  that  most  improves  the 
operators  level  of  d1’ s~atisfaction  with  the 
expected  goal  states. 
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Now,  there  are  many  ways  to  implement  a  procedure  like  that 
above.  Not  all  of  them  would  necessarily  be  less  complex  than  the 
general  utility  function  method.  There  are  several  aspects  of  the 
goal  seeking  approach,  however,  that  give  it  the  potential  of 
satisfying  the  objectives  of  1-0  above. 

First,  the  operators'  objectives  are  stated  as  a  discrete  set 
of  goals.  It  is  not  necessary  that  the  goals  be  independent.  In 
other  words,  the  sets  of  variables  used  to  evaluate  the  goal  states 
need  not  be  mutually  exclusive.  This  makes  the  'state  space,"  over 
which  data  must  be  collected  from  subject  matter  experts,  discrete 
rather  than  continuous.  Thus,  the  experts'  estimation  of  the  rela¬ 
tive  dissatisfaction  (called  "goal  priorities"  in  the  next  section) 
of  two  or  more  goals  can  be  obtained  by  pairwise  comparision3. 

These  comparisons  can  be  made  by  considering  only  a  limited  set  of 
variables  (i.e.,  "other  things  equal").  This  contrasts  with  the 
utility  function  approach  in  which  a  utility  value  must  be  assigned 
(or  derived)  which  is,  at  least  in  theory,  a  function  of  rll  of  the 
state  variables. 

Furthermore,  when  comparing  two  goals,  it  is  necessary  only  to 
rank  the  goals  for  various  values  of  their  goal  states  rather  than 
to  assign  cardinal  utility  values.  Naturally,  eventually  some 
(arbitrary)  scale  of  goal  dissatisfaction  ("goal  priority")  must  be 
established,  but  since  the  rankings  are  the  most  significant  aspects, 
it  is  easier  to  develop  a  scale  that  resolves  the  rankings  of  more 
than  one  expert  with  the  goal  approach  than  with  the  utility  method. 

Thus,  the  data  requirements  are  reduced  when  using  a  goal 
seeking  approach.  Also,  the  computational  burden  of  the  method 
need  not  be  excessive.  The  computation  of  the  goal  priorities  can 
be  simplified  by  using  a  restricted,  but  flexible  class  of  func¬ 
tional  forms  (this  will  be  discussed  in  Section  III  below)  which 
yield  a  goal  priority  from  a  goal  state.  Since  it  is  these  goal 
priority  functions,  not  the  goal  states,  which  are  parameterized, 
intuitive  editing  of  operator  task  sequencing  parameters  is  possible. 

Another  way  to  say  this  is  that  while  the  goal  states  may  be 
complex  functions  of  the  state  of  the  system,  the  priority  (or  dis¬ 
satisfaction  level)  of  the  goal  is  a  function  of  only  the  computed 
goal  state.  Therefore,  the  goal  priority  is  a  function  only  of  a 
single  variable,  and,  since  an  operator's  goal  seeking  behavior  is 
dependent  on  .the  priorities  of  the  goals,  this  behavior  can  be 
altered  by  editing  the  priority  func1- ' ons  only. 

To  illustrate,  consider  Figure  11-1.  Suppose  an  operator  has 
two  goals,  A  and  D.  The  goal  priority  functions  for  these  goals 
are  labelled  Ar  and  B  in  Figure  II-l.  The  goal  states  for  these 
goals  run  along  the  horizontal  axis  and  the  goal  priorities  are 
represented  on  the  vertical  axis.  At  a  goal  state  of  y,  the  line 
B  is  greater  than  the  line  A1  so  the  operator  assigns  a  higher 
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Figure  II-l.  Illustration  of  Goal  Priority  Function  Editing. 


priority  to  goal  B  than  to  goal  A  at  this  value  of  the  goal  state. 

The  situation  is  reversed  for  goal  states  greater  than  z.  For  goal 
states  less  than  z,  the  operator  will  select  actions  that  improve 
goal  B.  This  behavior  can  be  modified  by  altering  the  goal  prior¬ 
ity  functions  only.  Suppose  now  that  the  goal  priority  function 
for  god  A  is  line  A„  in  Figure  II-l.  Now  goal  B  is  most  important 
only  for  goal  states  less  than  x.  For  values  greater  than  x,  the 
operator  selects  actions  to  imi-  "3  goal  A.  Note  that  this  change 
in  behavior  was  ac ''".'mplished  without  modification  to  the  definitions 
for  the  goals  or  the  method  of  computation  of  the  goal  states.  Also, 
modifying  the  goal  priority  function  from  A^  to  A„  is  relatively 
intuitive  since  the  impact  of  the  change  is  readily  apparent. 

A  goal  seeking  method  based  on  this  discussion  was  selected 
and  is  presented  in  greater  detail  in  the  next  section.  In  fact, 
the  goal  seeking  approach  is  a  special  case  of  the  general  utility 
theory  ideas  discussed  earlier.  This  correspondence  between  the 
utility  and  goal  methods  will  also  be  showr  at  the  appropriate  time 
in  the  discussion  that  follows. 
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III.  THE  TASK  SEQUENCING  ALGORITHM 


1-0  GOAL  PRIORITY  FUNCTIONS 

The  goal  seeking  behevicr  of  the  operators  is  characterized 
by  the  following: 

1.  The  operators  have  a  set  of  goals  which  they  desire  to 
satisfy  simultaneously.  They  are  capable  of  deter¬ 
mining  the  value  or  state  of  each  goal.  For  example, 
the  operator  nay  desire  to  maximize  the  distance  from ! 
a  critical  asset  to  any  hostile  aircraft.  The  goal  i 
state  is  the  minimum  distance  to  any  hostile  track. 

*'  1  I ' 

2.  The  operators  can  rank  the  importance  of  their  goal  j 
states.  In  other  words,  they  can  assign  priorities 
to  their  goals  based  upon  their  current  states.  For 
example,  an  AN/TSQ-73  operator  can  determine  whether 

an  uncleared  alert  message  or  a  hostile  aircraft  within 
30  miles  of  a  critical  asset  should  be  attended  to  next. 

3.  The  operators  are  capable  of  estimating  the  changes 
that  will  occur  in  their  goal  states  if  a  particular 
task  is  performed. 

U.  Operators  are  limited  in  their  ability  to  satisfy  their 
goals.  They  may  not  be  able  to  consider  all  of  their, 
goals  at  once. 

These  concepts  are  implemented  in  the  following  ways.  For 
j  each  operator  goal,  the  goal  state  (denoted  GS)  must  be  explicitly 
specified  in  a  way  that  allows  GS  to  be  assigned  a  unique  value  l 
(e.g.,  GS  *  the  number  of  unassigned  hostile  tracks).  Then  a  goal 
j  priority  function,  GP,  is  specified  for  the  goal  that  assigns  a  non- 
|  negative  value  to  each  value  of  GS.  Figure  III-l  shows  an  hypothe- 
f  tical  example.  The  goal  is  satisfied  when  the  goal  state,  GS,  is 
between  m  and  M.  This  is  signified  by  GP  *  0  when  m  _<  GS  _<  M.  If 
the  goal  state  is  less  than  m  or  greater  than  M,  then  the  priority 
of  the  goal  (i.e.,  its  degree  of  dissatisfaction)  increases  linearly. 

Tne  meaning  of  the  particular  goal  priority  function  in 
figure  III-l  i3  that  the  operator  is  satisfied  and  indifferent  to 
any  value  of  the  goal  state  between  m  and  M.  Downside  deviations 
(i.e.,  values  of  GS  less  than  m)  are  apparently  more  important  than 
upside  deviations  (i.e.,  values  of  GS  greater  than  M)  since  the 
slope  for  downside  deviations  is  greater  than  the  slope  for  upside 
deviations . 
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Figure  III-l.  Example  Goal  Priority  Function. 


Each  goal  that  an  operator  has  may  have  a  different  priority 
function.  See  Figure  III-2  for  examples.  The  values  of  the  goal 
priorities  for  each  goal  are  compared  in  an  ordinal  fashion  during 
task  sequencing  to  determine  the  most  dissatisfied  goal  or  goals. 
This  scheme  allows  the  parameters  for  a  goal  priority  function  to 
be  specified  or  changed  without  affecting  the  priority  functions 
for  other  goals.  Of  course,  complete  independence  is  not  obtained 
because  the  modeler  must  always  be  aware  of  the  priority  functions 
of  the  rest  of  the  goals. 

In  order  to  simplify  the  implementation,  a  standard  functional 
form  for  goal  priority  functions  is  used  in  M0FAD3.  Six  parameters 
are  associated  with  each  goal  for  each  operator.  In  the  discussion 
that  follows,  subscripts  on  the  notation  are  suppressed  for  simpli¬ 
city.  The  reader  shouj  \  oe  aware,  however,  that  parameters  such  as 
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"little ’m"  should  be  written  m  to  indicate  the  parameter  value 
for  operator  i  and  goal  k. 

For  each  goal  a  range  of  satisfaction  (m,M)  is  specified.  If 
the  goal  state,  GS,  falls  in  this  interval,  then  the  goal  is  satis¬ 
fied  and  the  goal  priority,  GP,  is  zero.  For  values  outside  the 
range  of  satisfaction,  the  goal  priority  is  evaluated  using  an 
exponential  function  with  four  parameters  denoted  a,  b.  A,  and  B. 
The  complete  goal  priority  functional  form  is  given  below. 


If 

GS  <  a 

then 

GP  « 

a(m-GS)k; 

b 

>  0 

If 

m  <  GS  <  M 

then 

GP  « 

0 

If 

GS  >  M 

then 

GP  « 

A(GS-M)B; 

B 

>  0 

The  purpose  of  specifying  two  sets  of  exponential  parameters  (i.e., 
(&,b)  and  ( A, B) )  is  to  provide  different  priorities  for  "upside" 
deviation  above  the  range  of  satisfaction  and  "downside”  deviations 
below  the  range  of  satisfaction. 

This  functional  form  provides  considerable  flexibility  in 
specifying  goal  priority  function.  All  of  the  forms  in  Figure  III-2 
can  be  obtained  with  appropriate  values  of  the  six  parameters.  For 
example,  in  III-2(a),  b<l  and  B>1;  in  III-2(b),m  *  M  and  b  *  B  *  1. 
In  III-2(c),  m  *  -°°  and  B>1;  the  values  of  a  and  b  need  not  be 
specified.  In  III-2(d),  M  =  00  and  b  *  0.  Since  the  upside  and 
downside  priority  functions  may  be  specified  independently,  a  vide 
variety  of  functional  forms  can  be  obtained.  Of  course,  certain 
types  of  functions  cannot  be  represented;  for  example,  asymptotic 
priority  functions  are  not  possible. 

Certain  types  of  functions  are  prohibited  by  the  restriction 
that  b  >.  0  and  B  >  0.  Negative  exponents  result  in  functions  such 
as  that  shown  in  Figure  III-3.  With  B  <0,  the  priority  first 
increases  then  decreases  for  ever  increasing  deviations  from  the 
range  of  satisfaction.  Since  this  type  of  goal  priority  function 
represents  unusual  behavior,  the  MOFADS  software  does  not  accept 
priority  functions  with  b  or  B  negative  (the  MOPADS  user  can 
circumvent  this  representation  by  using  the  basic  user  interface 
•commands  EXAMINE  and  DEPOSIT  to  directly  insert  negative  values 
into  the  operator  state  vectors.  Descriptions  of  EXAMINE  and 
DEPOSIT  are  contained  in  Polito  (1983  ),and  the  goal  priority 
functions  for  the  IHAWK  and  AN/TSQ-73  are  contained  in  Goodin  & 

Walker  ( l?83a ,b). 

Specification  of  the  parameters  of  the  goal  priority  functions 
can  be  made  simple  and  intuitive  by  recognizing  that  a  and  b,  for 
example,  can  be  determined  uniquely  by  knowing  two  points  on  the 
downside  d“viation  function.  Suppose  we  know  two  such  points  as 
follows : 
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M 

GS 


F;lgure  III-3.  Example  of  Prohibited  Goal  Priority  Function-with  3<0. 

point  1  *  (GSlt  GP1) 
point  2  «  (GS2,  GP2) 

where  m  is  finite,  GS^  <  GS2  <  m  and  GP^  >_  GPp  >  G. 

The  logorithm  (to  any  base)  of  the  downside  priority  function  is 

log(GP)  =  log(a)  +  b  log(m  -  GS)  . 

Substituting  the  two  known  points  into  this  equation,  eliminating 
log(a),  and  solving  for  b  yields 

logCGPj^/GPg) 

b  ~  log( [m-GS1] / [u-GS2] ) 

Then,  solve  for  a  from 

GP 

a  =  _ ^ 

(m-GS1)b 
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Using  the  above  four  equations,  the  goal  priority  functions 
can  be  determined  automatically  from  intuitively  meaningful  data 
specified  by  the  user. 


2-0  THE  OPERATOR  OBJECTIVE  FUNCTION 

Suppose  an  operator  evaluates  his/her  goals  and  obtains  values 
for  each  goal  priority,  GP^,  i  *  1,  2...N  (where  N  is  the  number  of 
goals).  At  this  point  he  must  decide  which  goal  or  goals  he/r.he  will 
try  to  improve.  There  are  several  objectives  he/she  might  use. 

For  example,  he  might  try  to  improve  that  goal  state  which  has  the 
highest  goal  priority.  This  is  "putting  out  the  biggest  fire  first." 
Or  he  might  seek  a  course  of  action  that  would  improve  the  states 
of  several  goals  simultaneously.  An  operator  who  does  this  would  be 
taking  a  more  global  approach  to  problem  solving. 

The  operator  might  also  attempt  to  obtain  rapid  improve¬ 
ment  in  his/her  goal  states.  This  would  involve  estimating  the  time 
required  to  perform  the  various  options  available  to  him  and  select¬ 
ing  the  one  which  yields  the  most  rapid  improvement  in  one  or 
several  goals. 

MOPADS  provides  operator  objective  functions  which  can  account 
for  all  of  the  above  considerations.  Suppose  the  operator  considers 
NG  goals  (1  <_  NG  <_  N)  when  selecting  the  next  task.  Compute  weights 
for  the  NG  largest  goal  priorities  as  follows: 


GP 


i 


0-24 


IJotc  that  the  goal  priorities  have  been  ranked  from  highest  to  lowest 
and  the  are  computed  only  for  the  NG  largest  priorities. 

How  compute  the  special  weighted  average  goal  priority, 

AVHG,  as  follows: 

NG 

AVHG  *  2  (vA  GP1) 


WPG  la  the  composite  goal  priority  for  the  operator.  Hote  that 
the  highest  weight  is  assigned  to  the  most  dissatisfied  goal.  If 
HG  is  one,  then  AVHG  is  the  priority  of  the  most  dissatisfied  goal 
(the  "biggest  fire").  As  NG  increases,  the  operator  is  able  to 
consider  more  and  more  goals,  but  he  still  assigns  the  greatest 
weight  to  the  most  dissatisfied.  In  fact,  the  w^  assign  weights 
to  the  goals  that  are  proportional  to  each  goal's  contribution  to 
the  "total  dissatisfaction"  (i.e.,  the  sum  of  the  HG  most  largest 
goal  priorities). 

Wien  selecting  the  next  task,  the  operator  evaluates  AVHG  for 
the  current  goal  states,  then  the  outcomes  of  each  option  are 
evaluated  and  an  exported  value  of  AVHG  is  calculated  for  each 
option.  The  option  which  yields  the  greatest  expected  reduction  In 
AVHG  is  selected.  In  computing  the  expected  values  of  AVHG,  the 
values  of  w^  are  not  re-computed  and  the  same  set  of  HG  goals  are 
used  as  in  computing  the  current  value  of  AVHG.  If  the  operator 
seeks  rapid  improvement  in  his/her  goals,  then  an  estimate  of  the 
time  to  perform  each  option  is  made,  also,  and  the  improvement  in 
AVHG  is  divided  by  this  time  to  obtain  the  improvement  per  minute. 
The  option  that  yields  the  greatest  improvement  per  minute  is 
selected. 

As  stated  earlier,  this  formulation  can  be  stated  in  a  utility 
theory  framework.  The  utility  function  is  AVHG  which  is  a  function 
of  HG  and  the  goal  priorities,  i.e.,  AVHG  (HG,  GP^,  GP,,,  ...GP^). 
Each  of  the  goal  priorities  is  a  function  of  its  related  goal  state 
which  is  in  turn  a  function  of  the  state  of  the  system,  S: 

U(S)  *  AVHG(HG,GPi(GSi(B)),  i  *  1,  2,...H) 


The  operator's  seek  to  minimize  the  uoove  utility  function. 

Thus  the  goal  seeking  methodology  is  a  special  case  of  utility 
theory  in  which  the  utility  function  has  been  restricted  to  a 
special  class  of  parametric  expressions  vhich  are  fairly  easy  to 
deal  with.  The  intermediate  functions,  GP^ ,  are  adjusted  by  the 
user  to  affect  the  decision  making  behavior  of  the  simulated 
operators . 


3-0  A  PRECISE  STATEMENT  OF  THE  T/SK  SEQUENCING  ALGORITHM 

Before  a  formal  specification  of  the  task  sequencing  algorithm 
can  be  given,  two  more  concepts  must  be  introduced.  First,  MOPADS 
maintains  a  last-in-firat- out  stack  of  operator  tasks  which  the 
operator  will  perform.  This  is  because  in  task  sequencing  the 
operator  may  select  to  sequentially  perform  two  related  tasks.  Alter 
each  task  the  operator  returns  to  the  task  sequencing  procedure, 
but  if  the  stack  is  non-  empty,  the  next  task  on  the  stack  is 
selected  automatically  without  a  complete  goal  evaluation.  An 
example  of  a  situation  where  this  capability  is  needed  concerns  the 
Azimuth  Speed  Operator  (ASO)  in  the  IHAWK.  This  operator  has  two 
tasks  (Detect  New  Target  and  Establish  Target  Priority)  which  are 
always  performed  in  sequence.  The  second  task.  Establish  Target 
Priority,  is  loaded  on  his/her  task  stack  when  the  first  task  is 
selected. 

I 

Secondly,  a  method  is  also  provided  to  interrupt  this  stack 
processing.  Interruptions  are  always  caused  by  high,  priority 
messages.  The  artifact  used  to  implement  this  in  MJPADS  is  to 
make  the  priority  of  interrupting  messages  negative.  When  an  in¬ 
terrupting  messag .  is  present,  a  normal'goal  evalation  takes  place 
"  en  if  the  task  stack  is  non-empty. 

j 

Finally,  some  sequences  of  tasks  on  the  task  stack  are  so 
important  in  terms  of  mission  accomplishment  and  in  terms  of  correct 
operation  of  the  MOPADS  models  that  a  method  is  provided  to  over¬ 
ride  the  interrupting  message  mechanism.  This  is  a  programming 
convenience  that  allows  the  MOPADS  modeler  to  ensure  that  certain 
illogical  contingencies  do  not  occur  in  the  m^del. 

Also,  while  it  is  not  strictly  v  part  of  task  sequencing,  an 
operator  can  be  interrupted  during  the  jjprformance  of  a  task  element 
using  normal  MSAINT  features.  Thus  it  is  possible  with  MOPADS  to 
interrupt  the  actions  of  an  operator  during  the  performance  of  an 
operator  task  as  well  as  between  the  performance  of  operator  tasks. 

Figure  III-U  shows  a  flow  chart  of  the  task  sequencing  algor¬ 
ithm.  If  the  stack  is  empty  at  decision  1,  a  complete  goal,  evalua¬ 
tion  is  performed  starting  at  box  5.  Otherwise,  decision  2  deter¬ 
mines  if  the  stack  may  be  interrupted;  if  not  the  next  task  is 
selected  from  the  stack  at  box  3.  If  the  stack  can  be  interrupted, 
decision  U  determines  if  interrupting  messages  are  present.  If  not, 
the  stack  is  not  interrupted  and  the  next  task  is  selected  at  box  3. 
If  interrupting  messages  exist,  a  goal  evaluation  is  performed 
beginning  at  box  5* 

The  goal,  states  are  computed  at  box  5.  Example  goal  states 

are : 

1.  The  maximum  priority  of  any  message  for  this  operator.  1 
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Figure  III— U «  The  Task  Sequencing  Algorithm. 
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2.  The  minimum  time  for  any  hostile  aircraft  to  arrive- 
at  any  protected  site. 

3.  The  number  of  unidentified  tracks. 

The  goal  priorities  are  calculated  at  box  6  using  the  goal  states 
and  the  exponential  functions  discussed  in  Section  1-0  above. 

AVNG  is  computed  at  box  7  as  discussed  in  Section  2-0  above 

In  box  8,  the  list  of  available  operator  tasks  is  examined. 
For  each  available  task,  an  estimate  is  nude  of  the  expected 
changes  that  will  occur  to  the  goal  states.  These  expected  goal 
states  are  used  to  compute  expected  values  of  the  goal  priorities 
and,  finally,  of  AVNG.  If  the  operator's  objective  is  to  rapidly 
reduce  AVNG,  then  an  estimate  of  the  time  to  perform  each  available 
task  is  also  obtained. 

Suppose  AVNGJ  is  the  expected  value  of  AVNG  if  operator  task  j 
is  selected  andTJ  is  the  estimated  time  to  perform  task  j.  Then 
for  each  task  J  compute : 


DELJ  =  AVNG-  AVNGJ 
or 

DELJ  =  (AVNG  -  AVNGJ )/TJ 

and  select  task  J  which  gives  the  largest  value  of  DELJ.  Each 
operator  has  an  idle  or  scan-screen  task  which  is  selected  if  all 
DELJ  are  negative  or  if  no  other  task  can  be  selected.  This 
activity  is  performed  at  box  9  of  Figure  III-4. 
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IV.  IMPLEMENTATION  OF  THE  TASK  SEQUENCING  PROCEDUE 


i 


1- 0  TASK  SEQUENCING  SUBPROGRAMS 

The  task  sequencing  procedure  has  heen  organized  in  a  modular 
vay  to  facilitate  modification  of  additions  of  additional  system 
modules.  Figure  IV-1  shows  the  structure  of  the  software.  The 
four  programs  ending  in  "Y",  TSEQY,  GEVALY,  GFRIY,  and  OEVALY,  are 
contained  in  the  common  system  module  programs,  Goodin  &  Polito 
(1983b),  and  need  only  minor  modification  as  new  system  modules  are 
added. 

SUBROUTINE  GEVALY  is  responsible  for  evaluating  the  goal 
states,  GS^,  at  box  5  in  Figure  III-U.  It  calls  a  separate  sub¬ 
routine  for  each  system  module  type  (o.g.,  IHAWK,  AN/T3Q-73) .  The 
three  programs  GEVALG,  GEVALQ,  and  GEVALW  evaluate  the  goals  for 
the  operators  of  that  particular  system  module  type.  For  example, 
GEVALQ  calls  programs  GEV1Q,  GEV2Q,  etc.  to  evaluate  the  goal  states 
for  goal.  1,  goal  2,  etc.  of  the  battalion  AN/TSQ-73  operators. 

SUBROUTINE  OEVALY  is  responsible  for  calculating  the  expected 
goal  states  that  will  result  from  selection  of  available  operator 
tasks  (box  8  in  Figure  III-U).  OEVALY  cedis  a  program  for  each 
system  module  type  (OFVALG,  OEVALW,  or  OEVALQ) .  The  organization 
in  Figure  TV-1  is  used  for  the  IHAWK.  OEVALW  calls  a  program  for 
each  operator  type.  For  example,  0EAS0W  is  called  to  evaluate  tasks 
performed  by  the  ASO. 

Programs  which  are  specific  to  a  particular  system  module  type 
are  documented  in  the  reference  report  for  that  system  module.  For 
example,  all  subprograms  ending  in  the  letter  Q  in  Figure  IV-1  are 
contained  in  Goodin  &  Walker  (1983a). 

Modification  of  the  task  sequencing  programs  for  the  IHAWK 
ASO  would  require  changes  to  only  SUBROUTINE  0EAS0W.  Addition  of 
a  new  system  module  would  require  trivial  modification  to  GEVALY 
and  OEVALY, and  then  programs  analogous  to  GEVALQ  and  OEVALQ  and 
their  descendents  would  need  to  be  written. 

2- 0  TASK  STACK  PARAMETERS 

The  task  stack  is  more  than  a  list  of  tasks  to  be  performed. 
Associated  with  each  task  is  a  list  of  four  parameters  which  can 
be  retrieved  at  any  time.  The  parameters  are  used  to  pass  informa¬ 
tion  to  MOPADS  about  a  task  being  performed.  For  example,  if  an 
AN/TSQ-73  operator  selects  a  task  to  assign  a  track  to  a  fire  unit, 
the  track  number  and  the  fire  unit  identifier  will  be  stored  as 
parameters  in  the  stack  for  later  retrieval  when  the  task  is 
performed. 


0-29 


A  task  sequencing  pr>cedure  fov  a  new  system  module  can  be 
developed  by  using  the  existing  programs  as  guides,  and  making  use 
of  the  stack  parameter  feature. 


V.  AN  EXAMPLE  OF  GOAL  PRIORITIES 


There  are  three  important  steps  in  developing  a  task 
sequencing  procedure  for  an  operator: 

1.  determining  the  operator’s  goals, 

2.  specifying  the  goal  priority  functions,  and 

3.  -writing  the  subprograms  GEVAL?  and  OEVAL?  That 
evaluate  the  goal  states  and  estimate  changes  to  the 
goal  states  that  will  result  from  performing 
various  operator  tasks. 

Steps  one  and  two  require  discussion  with  subject  matter 
experts,  and  they  require  modeling  Judgement.  An  operator's  goals 
munt  he  sufficient  to  motivate  the  simulated  operator  to  perform  all 
of  his/her  tasks  if  the  correct  conditions  arise.  Seme  of  the 
operator's  gcals  will  be  straightforward.  Subject  matter  experts 
will  readily  identify  them.  For  example,  a  goal  of  the  I  HAWK 
Tactical  Control  Officer  (TCO)  is:  maximize  the  minimum  time  to 
arrive  at  any  protected  site  of  any  threatening  airc  aft.  This 
goal  motivates  the  TCO  to  take  actions  that  protect  his  critical 
assets. 

Other  goals,  however,  may  need  to  be  added  as  modeling  con¬ 
veniences  in  order  to  accommodate  the  way  the  MOFADS  software  repre¬ 
sents  information.  For  example,  the  ICO  also  has  the  goal  "minimize 
the  maximum  priority  oi  outstanding  messages."  This  "goal"  is  a 
surrogate  for  the  TCO's  obvious  attention  to  messages  from  a  Batta¬ 
lion  or  Group  AN/TSQ-T3  and  to  voice  communications  from  other  members 
of  the  IHAWK  crew.  MOFADS  represents  all  of  these  communications  as 
messages,  and  it  would  be  impractical  to  specify  a  separate  goal  for 
responding  to  each  of  these  communication  channels.  This  goal  is 
somewhat  contrived,  but  does  reflect  real  behavior  by  the  bperator. 

It  also  allows  subject  matter  experts  to  give  their  intuitive 
priorities  to  the  various  messages  that  the  operator  receives. 

The  goals  for  the  IHAWK  TCO  are  shown  in  Table  V-i.  Goal 
six  may  need  some  explanation.  The  IHAWK  will  engage  unknown  pop¬ 
up  targets  that  threaten  it  or  its  assets.  Pop-up  targets  may  be 
engaged  without  being  identified  if  events  occur  so  quickly  that 
identification  is  precluded.  However,  if  such  an  aircraft  is 
identified  as  friendly  during  the  course  of  an  engagement,  the 
TCO  will  immediately  take  action  to  prevent  the  aircraft  from 
being  destroyed.  In  the  current  MOFADS  simulations,  this  situa¬ 
tion  is  the  only  one  in  which  a  friendly  aircraft  will  be  engaged. 


Table  V-l.  Goals  for  the  IHAWK  Tactical  Control  Officer. 


1.  ENGAGE  ASSIGNED  TRACKS 

&?al  State:  The  minimum  time  for  any  In  range, 

assigned, but  not  engaged, track  to 
arrive  at  the  IHAWK  or  Its  pro¬ 
tected  site  if  it  immediately 
turned  inbound 


The  minimum  time  for  any  hostile 
or  unknown,  not  receding,  un¬ 
assigned  track  to  arrive  at  the 
IHAWK  it  it  immediately  turned 
inbound 


The  minimum  time  for  any  hostile 
or  unknown,  not  receding,  un¬ 
assigned  track  t^  arrive  at  a 
protected  site  if  it  immediately 
turned  inbound  to  the  site 


4.  ATTEND  TO  MESSAGES 

Goal  State:  The  maximum  priority  of  any  out¬ 

standing  messages 


3.  PROTECT  CRITICAL  ASSETS 
Goal  State: 


2.  SELF  DEFENSE 
Goal  State: 


5.  CONSERVE  AMMUNITION 

Goal  State:  The  total  number  of  hot  and  cold 

missile  available  less  those 
expected  to  be  fired  at  currently 
engaged  tracks 


6.  PROTECT  FRIENDS 

Goal  State:  Number  **f  friendly  tracks 

currently  being  engaged 
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Figure  V-l  shows  a  set  of  candidate  goal  priority  functions 
for  the  goals  given  in  Table  V-2  .  The  goal  priority  functions  are 
identified  by  the  goal  number  enclosed  in  a  circle.  By  convention, 
a  goal  priority  value  of  10  is  considered  an  emergency.  Thus,  for 
goal  two,  an  aircraft  less  than  about  1.3  minutes  from  the  IHAWK 
constitutes  an  emergency,  and  the  TOO  would  select  action*  to 
immediately  attack  such  an  aircraft.  Rote  that  in  the  region  less 
than  1.3  minutes,  self  defense  (goal  2)  as  the  most  important  goal 
followed  by  protection  of  critical  assets  (goal  3).  Both  of  these 
goals  take  priority  over  similar  tracks  assigned  by  a  Battalion  . 
AN/TSQ-73.  At  a  time  greater  than  1.3  minutes,  the  situation  is 
reversed,  however,  and  the  TCO  would  engage  tracks  assigned  from 
the  battalion  before  self- initiating  engagements  on  other  tracks. 

Note  that  self  defense  and  protection  of  critical  assets 
takes  precedence  over  protection  of  friendly  aircraft  in  the  critical 
range  below  1.3  minutes  but  not  above  this  time.  The  TCO  is  con¬ 
cerned  about  conserving  ammunition  only  when  three  or  less  remain, 
since  this  is  the  number  of  missiles  on  one  launcher. 

The  priority  functions  for  messages  is  the  same  as  the  message 
priority.  In  other  words,  a  message  whose  priority  is  5  has  a  goal 
priority  of  5,  also.  Be  sure  to  note  that  the  goal  state  axis  at 
the  bottom  of  Figure  V-l  has  different  units  depending  on  the  par¬ 
ticular  goal.  It  is  possible  that  goal  one  has  a  goal  state  of 
three  minutes  which  implies  a  goal  priority  of  about  three  while  the 
highest  priority  outstanding  message  has  priority  six.  In  this  case 
the  goal  priority  function  for  goal  four  would  have  a  value  of  six, 
and  the  TCO  would  respond  to  the  message  before  attending  to  an 
assigned  track. 

The  goal  priority  functions  in  Figure  V-l  were  developed  in 
consultation  with  subject  matter  experts  by  asking  them  pairwise 
type  questions.  For  example,  "Which  is  of  greater  concern  to  the 
TCO,  an  unengaged  hostile  aircraft  within  2  minutes  or  a  new  assign¬ 
ment  message  from  the  Battalion?"  The  results  of  these  discussions 
can  be  synthesized  to  goal  priority  functions  whose  ordinal  rankings 
reflect  the  priorities  of  the  experts.  This  task  is  made  easier  by 
the  fact  the  ordinal  rather  than  cardinal  rankings  are  most  signi¬ 
ficant.  For  example,  consider  goal  2  (self  defense)  and  goal  6 
(protect  friendly).  The  significant  characteristics  of  their  goal 
priority  functions  is  that  for  a  goal  2  goal  state  under  about  1.3 
minutes,  the  self  defense  goal  is  more  important  than  protecting 
friendly.  The  amount  by  which  the  goal  2  priority  exceeds  the  goal 
6  priority  is  not  significant.  This  fact  greatly  simplifies  the 
task  of  developing  goal  priority  functions. 

The  task  sequencing  algorisms  presented  in  this  report  sep¬ 
arates  the  f motions  of  goal  evaluation,  goal  priority  evaluation, 
ar;d  task  selection.  By  doing  so,  it  simplifies  the  third  step  in 
developing  a  task  sequencing  procedure,  i.e.,  writing  the  subprog¬ 
rams  that  evaluate  goal  states  and  estimate  the  impact  on  goal 


Note:  The  units  of  the  goal  state  axis  are  not 
the  same  for  a1'«  goals. 
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states  of  various  operator  actions.  These  subprograms  can  be 
developed  vithout  regard  to  hov  the  operrtor  vill  veight  the 
importance  of  the  goals. 

The  modularity  achieved  by  this  goal  seeking  methodology: 

1.  permits  goal  evaluation  programs  to  be  written 
independently  of  other  goals. 

2.  allows  the  MOPADS  user  to  alter  an  operator's  goal 
seeking  behavior  by  changing  only  parameters  of 
the  goal  priority  functions, 

3.  allows  automatic  generation  of  goal  priority  functions 
from  intuitive  inputs  from  the  MOPADS  user,  and 

U.  causes  the  simulated  operators  to  respond  to  the  air 
battle  in  a  rational  manner. 

Thus,  the  methodology  satisfies  all  of  the  desirable  features  of  a 
task  sequencing  method  discussed  in  Section  II,  1-0. 
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I.  INTRODUCTION 


This  manual  is  intended  as  a  guide  for  both  authors  and  typists 
of  MOPADS  reports.  Its  purpose  is  to  ensure  uniform  organization 
for  JiCPADS  reports ,  to  expedite  the  distribution  of  reports ,  and 
to  satisfy  contractual  requirements  for  form  and  format . 

Authors  will  be  primarily  concerned  with  Section  II  which 
describes  report  organization.  Topics  discussed  in  this  section 
are  section  and  subsection  numbering,  figure  and  table  numbering, 
and  preparation  of  references  and  footnotes. 

Typists  must  also  be  familiar  with  Section  II ,  but  they  will 
be  most  concerned  with  Sections  III  and  IV.  These  last  two  sec¬ 
tions  describe  typing  and  delivery  of  reports. 

The  requirements  presented  in  the  subsequent  sections  are 
minimal  and  should  not  hinder  preparation  of  reports.  Any  special 
cases  which  arise  should  be  discussed  with  the  Pritsker  &  Associates 
Project  Leader. 
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II.  REPORT  ORGANIZATION 


1-0  SECTION  AND  SUBSECTION  ORGANIZATION. 

Figure  II-l  is  an  example  Table  of  Contents  for  u  MOPADS 
report.  It  shows  hcv  major  sections  and  subsections  are  to  be 
designated.  Important  features  of  this  organization  follow. 

1-1.  Major  sections  are  designated  by  Roman  Numerals. 

Titles  are  in  upper  case  and  no  text  is  inserted  between  the  major 
section  title  and  the  first  subsection.  Major  sections  begin  new, 
right-hand  pages . 

1-2.  First  subsections  are  numbered  1-0  j  2-0,  3-0,  etc.  A 
first  subsection  has  a  title  and  is  capitalized.  No  text  appears 
on  the  same  line  as  a  first  subsection  heading. 

1-3.  Second  subsections  are  numbered  1-1,  1-2,  1-3,  etc.  The 
first  few  words  of  these  sections  may  be  underlined.  Also,  text  may 
begin  on  the  same  line  as  the  subsection  title . 

1-U .  Third  subsections  are  lettered  with  lower  case  letters, 
e.g.,  1-2. a,  1-2. b,  etc.  The  first  few  words  of  the  title  may  be 
underlined,  and  text  may  begin  on  the  same  line  as  the  subsection 
number /letter . 

1-5-  The  beginning  of  each  subsection  is  indented  six  spaces. 
Subsequent  text  extends  fully  from  the  left  to  the  right  margins. 


2-0  FIGURES  AND  TABLES. 

2-1.  Figures . 

Figures  will  be  placed  on  a  separate  page  and  will  be 
numbered  consecutively  within  major  sections  (e.g.,  1-1,  1-2,  II-l, 
II-2,  etc.).  Figures  must  fit  within  the  typing  guide  (see  Section 
III),  but  figures  may  be  continued  to  additional  pages.  Figure  II-2 
is  a  sample  of  a  List  of  Figures  page  and  Figure  II-3  is  a  sample 
figure .  Note  that  the  figure  title  appears  at  the  bottom  of  the 
page  on  the  margin  line.  The  format  shown  in  these  figures  should 
be  followed.  Computer  output  may  be  used  as  figures. 

Generally,  foldout  pages  are  to  be  avoided,  but  very  large 
figures  which  will  be  difficult  to  breakup  or  reduce  may  be  presented 
on  foldouts .  Authors  must  retain  original  drawings  in  case  refor¬ 
matting  is  later  required. 
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Figure  II-2.  Sample  List  of  Figures. 
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MOPADS  PROGRESS 


2-2. 


'ables . 


Tables  vill  be  numbered  consecutively  in  each  major 
section  (e.g.,  1-1,  1-2,  II-l,  II-2,  II-3,  etc.).  Table  titles 
will  be  centered  above  the  table,  and  more  than  one  table  may 
appear  on  a  single  page  if  they  vill  fit.  Tables  may  also  be 
continued  tc  more  than  one  page.  Foldout  pages  are  also  permitted. 

Figurri  II-U  is  a  sample  List  of  Tables,  and  Figure  II-5  is 
a  sample  table.  The  format  shown  in  these  figures  should  be 
followed.  S 


Computer  output  may  be  used  in  tables ,  but  must  conform  to 
margin  requirements,  see  Figure  II-6.  Program  listings  and  other 
long  output  should  be  put  in  appendices.  As  a  rule,  long  program 
lists  will  riot  appear  in  reports  since  the  programs  themselves  are 
deliverable i items . 


3-0  REFERENCES  AND  FOOTNOTES. 


3-1 .  References , 


References  cited  in  the  text  and  listed  in  the  REFERENCES 
section  will  confor.n  •* o  the  recommended  format  of  the  American 
Psychological  Association.  The  reference  for  this  standard  is: 

Publication  Manual  of  the  American  Psychological 
Association,  2nd  ed. 

Copies' may  be  ordered  from  Publication  Sales,  APA,  1200 
Seventeenth  St.,  N.W.,  Washington,  D.C.,  20036. 


Pages  59  through  63  of  this  manual  contain  the  pertinent 
material  on  references.  References  to  other  M0PADS  reports  should 
include  the  term  "K0PADS"  (e.g.,  M0PADS  Volume  5.3).  Figure  II-7 
is  a  sample  REFERENCE-  section. 


3-2 .  Footnotes . 

i 

Footnotes  will  be  numbered  consecutively  throughout  the 
report.  Footnotes  will  appear  on  the  page  they  are  noted.  Long 
footnotes  should  be  incorporated  in  the  text  or  left  out.  Footnotes 
are  designated  as  follows:  £/  Jj .  This  notation  is  used  both  in 
the  text  and  at  the  bottom  of  the  page  where  the  footnote  text  appears. 

Footnotes  in  figures  and  tables  will  use  strings  of  asterisks 
(e.g.,  "*",  "***”). 


4-0  APPENDICES. 

Appendices  are  major  sections  that  are  designated  by  capital 
letters  instead  of  Roman  numerals  (e.g..  A,  B,  etc.).  Tables  and 
Figures  will  be  numbered  within  the  appendix  as  in  other  major 
sections  (e.g.,  A-l,  A-2,  etc.). 
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Figure  II-U.  Sample  List  of  Tables. 


Table  I 1-3 


AN/TSQ-73  FLOWCHART  CODES 


DC 

- 

Display  Console  Controls 

E 

- 

AN  Keyboard  Entry 

RIE 

- 

RIE  Panel  1 

KPU 

- 

Requires  use  of  keyboard  printing  unit 

R 

- 

System  Response 

Numeric  codes : 

DC  -  Display  console  controls 
XX.YY.ZZ 

1 
2 

3 

4 

5 

6 

7 

8 
9 

10 
11 
12 

13 

14 

15 

16 


Figure  II-5-  Sample  Table. 


XX: 

Alerts 

Background  data  display 

Track  data  display 

Fire  unit  data  display 

System  mode 

Task  selections 

Task  functions 

Faults 

Symbol  brightness 
Video  brightness 
Video  selections 
ARO  data  selections 
Voice  comm  station 
AN  keyboard 
VAR  SCALE 
POSN  TAB 

YY:  Row  number 
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Table  II-l* 


INDEPENDENT  VARIABLES-APTITUDE 


RISK  ACCEPTANCE 

INTELLEGENCE 

AGE 

OPERATOR  TYPE 
SENSE  OF  DIRECTION 
WILLINGNESS  TO  TAKE  RISKS 
OBSERVATION  NOISE 
PERCEPTUAL  TIME  DELAY 
MOTOR  NOISE 

OPERATOR  GAIN  •  <8!<9  COMBINED) 
GENERAL  PROFICIENCY  FACTOR 
THRESHOLD  CONTRAST 
ASPIRATION  LEVEL 
OPERATOR  PRECISION 
TEAM  SKILL  LEVEL 
TRACKING  ABILITIES 
MOTIVATION  LEVEL 
VISUAL  ACUITY 
GENERAL  APTITUDE  SCORE 
MORALE  LEVEL 
LEADERSHIP  ABILITY 


Table  II- 5 

INDEPENDENT  VARIABLES-LEARNING/PRAC1 ICE 


#  PRACTICE  TRIALS 

TIME  SINCE  LAST  PRACTICED 

AMOUNT  OF  OVERLEARNING 

TIME  SINCE  INITIALLY  LEARNED 

TRAINING  EMPHASIS (SPEED  VS  COORDINATION) 

AMOUNT  OF  TRAINING 

PRESENCE  OF  FEEDBACK 

NUMBER  OF  CORRECT  CHOICES 

MASSED  VS  DISTRIBUTED  PRACTICE 

AMOUNT  OF  INITIAL  TRAINING 

TYPE  OF  FEEDBACK 

*  SUCCESSFUL  TRIALS 


Figure  II-6.  Sample  Tables  with  Computer  Output. 
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Figure  II-7-  Sample  References. 
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5-0  COMPUTER  OUTPUT  ' 

All  computer  output  in  figures  and  tables  will  be  trimmed, 
and  pasted  before  duplication  for  u  professional  appearance.  No 
lines  from  lined  paper  or  tractor  holes  should  be  visable. 

Long  lists  of  raw  computer  generated  information  are  to 
bo  avoided.  Where  such  data  can  be  considered  a  deliverable  item, 
magnetic  tapes  will  be  delivered  and  only  pertinent  sections  will 
be  reproduced  in  reports.  This  restriction  is  not  intended  to 
preclude  the  use  of  computers  to  generate  graphical  or  tabular 
information  for  use  as  tables  and  figures. 


III.  REPORT  PREPARATION 


\ 


1-0  ARRANGEMENT  OF  THE  REPORT. 

The  report  will  be  arranged  as  shown  in  Figure  II-l .  Each 
section  is  described  briefly  below. 

1-1.  Cover .  Company  covers  may  be  used  until  a  standard 
MOPADS  cover  is  available.  The  MOPADS  volume  number  and  date 
appear  in  the  upper  right  corner  of  the  cover.  See  Figure  III-l 
for  an  example. 

1-2.  Title  Page.  A  sample  title  page  is  shown  in  Figure 
III-2.  The  format  of  the  title  page  must  be  followed  exactly. 

1-3.  Disclaimer  Statement.  This  statement  will  appear  in 
all  MOPADS  documents.  Figure  III-3  contains  the  disclaimer.  It 
may  be  copied  and  used  directly  in  future  documents . 

1— U .  DDll73.  This  form  will  be .prepared  by  Pritsker  & 
Associates  when  the  document  is  distributed.  Preparers  must  leave 
space  for  it.  A  sample  is  shewn  in  Figure  III-U. 

1-5 .  Table  of  Contents,  List  of  Figures ,List  of  Tables, 
Abbreviations  and  Terminology.  See  Figures  II-l,  2,  U,  and  III-5 
for  samples . 

1-6.  Main  Body  of  Report.  Text. 

1-7.  References .  Figure  II-7  is  a  sample. 

1-8.  Appendices .  When  appendices  are  present,  they  should 
be  placed  directly  after  the  references.  For  bulky  apendices, 
appendices  may  be  bound  separately.  The  appendix  section  must 
contain  a  note  explaining  the  separate  binding.  The  separately 
bound  appendices  will  contain  the  table  of  contents  for  the  entire 
volume  but  only  the  text  for  the  appendices. 

1-9.  Distribution  List.  Distribution  will  be  coordinated 
with  the  Pritsker  &  Associates  Project  Leader  prior  to  duplica¬ 
tion.  As  a  general  rule,  the  distribution  list  shown  in  Figure 
III-6  will  be  used. 

1-10.  Change  Notices.  This  section  will  contain  the  cover 
pages  of  change  notices.  The  section  will  be  present  but  empty 
when  the  document  is  first  prepared. 
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Figure  III-l,  Sample  Cover  Page 
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Figure  III-2.  Sample  Title  Page. 


The  views,  opinions,  and/or  findings  contained  in 
this  report  are  those  of  the  authors  and  should 
not  be  construed  as  an  official  Department  of  the 
Army  position,  policy,  or  decision,  unless  so 
designated  by  other  official  documentation. 


Figure  III-3.  Disclaimer  Statement. 
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ABBRP'IATIONS  AND  TERMINOLOGY 


1- 0  ABBREVIATIONS 

(This  section  starts  on  a  new  page.) 

BCC  Battery  Control  Central 

CWAR  Continuous  Wave  Acquisition  Radar 

CWTDC  Continuous  Wave  Target  Detection  Console 

FC  Firing  Console 

HIFIR  High  -Powered  Illuminator  Radar 

PCe  Platoon  Command  Post 

TAS  Tracking  Adjunct  System 

TCC  Tactical  Control  Console 

TDECC  Tactical  Display  and  Engagement  Control  Console 

2- 0  STANDARD  MOPADS  TERMINOLOGY 

(See  Appendix  A  for  contents  of  this  section.  This  section 
starts  on  a  new  page.) 

3- 0  OTHER  TERMINOLOGY 

(As  required  for  the  report.  Use  the  format  in  Appendix  A.) 


Figure  III-5.  Sample  Abbreviations  and  Terminology. 
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Figure  III-6.  Distribution  List. 


2-0  TYPE  FACE,  MAEGINS,  AND  SPACING. 

2-1 .  Type  Face. 

An  Elite  12  (12  characters/inch)  t>pjng  element  will 
be  used  for  the  text  typing  of  all  reports  (this  requirement  does 
not  apply  to  computer  output  used  in  figures  and  tables).  It  is 
reconmended  that  major  section  headings  be  typed  in  upper  case 
with  an  Orator  element.  This  may  not  be  possible  if  the  report  is 
produced  on  a  word  processor,  hence  upper  case  Elite  32  is 
acceptable . 


2-2.  Margins . 


variation . 


The  margins  shown  below  are  to  be  used  without 


Top  Edge: 
Left  Side: 
Flight  Side: 
Bottom  Edge : 
Page  No : 
Text  Body: 


3/U"  from  top  of  paper 

1-3/4”  from  side  of  paper 

1-1/8"  from  side  of  paper 

1-10/16  from  bottom  of  page 

1-1/8”  from  bottom  of  paper,  centered 

5-1/2"  wide  by  8-1/2"  high 


The  above  assumes  8-1/2"  x  11"  paper.  The  margins  are 
designed  to  provide  correct  margins  when  duplicated  on  8"  x  10-1/2" 
paper.  A  sample  typing  guide  is  shown  in  Figure  HI-7 .  Originals 
for  local  reproduction  may  be  obtained  from  Pritsker  &  Associates- 
or  may  be  copied  from  the  sample  in  Appendix  B. 


2-3.  Spacing. 


The  following  rules  apply  for  spacing. 

1.  Text  will  be  single  spaced. 

2.  Double  space  between  paragraphs. 

3.  Double  space  between  subsections  and  between  . 
subsection  headings  and  text  in  that  subsection. 

U.  Double  space  after  table  number  and  table  title. 

5.  Double  space  twice  after  a  major  section,  table 

of  contents,  list  of  figures,  list  of  tables, 
abbreviations,  references,  appendices,  distribution 
list,  and  charge  notices. 

6.  Indent  six  spaces  for  each  subsection  heading  and 
for  new  paragraphs. 

7.  Triple  space  before  the  beginning  of  first  sub¬ 
sections  (2-0,  3-0,  etc.). 
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3-0  PRELIMINARY  PAGES  AND  PAGE  NUMBERING. 


3-1 •  Preliminary  Pages . 

The  preliminary  pages  are  made  up  of  the  following: 

1.  Cover  and  title  page 

2.  Disclaimer  statement 

3.  DD1173 

U.  Table  of  Contents 

5.  List  of  Figures 

6.  List  of  Tables 

7.  Abbreviations 

3-2.  Page  Numbering. 

Pages  are  numbered  as  follows : 


Page 

cover 
title  page 

disclaimer  statement 
DD1U73 

Table  of  Contents 
List  of  Figures 
List  of  Tables 
Abbreviations 

Main  body 


Appendices 


Page  numbers  will  be  centered  at  tl 
the  bottom  margin  (see  Figure  III-’ 


Number 

not  numbered 

i  (not  numbered) 

ii 

iii  and  iv  (not  numbered) 

v 

vi 

vii 

viii 

numbered  within  major  sections 
(e.g.,  1-1,  1-2) 

numbered  within  appendix 
(e.g. ,  A-l,  A-2) 

bottom  of  the  page  1/2”  below 


h-0  A  LIST  OF  KEY  WORDS  AND  AESTRAC'T. 

A  list  of  "key  words"  is  to  be  provided  to  Pritsker  &  Associates 
when  the  reports  are  delivered.  These  words  will  be  incorporated 
into  the  DDlU?3. 

An  abstract  is  to  be  written  for  each  report  and  also  sent 
on  a  separate  sheet  of  paper  to  Pritsker  &  Associates  when  the 
reports  are  delivered. 


P-29 


P-30 


IV.  DELIVERY  OF  THE  REPORT 


1-0  DISTRIBUTION  AND  BINDING. 

1-1.  Binding. 

Reports  one  Inch  (l")  thick  or  less  will  be  bound  with 
General  Binding  Corporation  combs .  Reports  over  one  inch  will  be 
bound  in  three-hole  loose  leaf  notebooks.  Long  reports  should  be 
copied  on  both  sides  of  the  pages  to  fic  within  the  one  inch  size 
if  possible. 


1-2.  Distribution. 

Distribution  of  copies  will  be  handled  as  follows: 

1-2. a.  The  author  will  keep  the  "original”  in  a 
camera-ready  form  (i.e.,  copied  on  one  side  of  the  paper,  unbound, 
no  holes ,  staples ,  etc . ) . 

i 

1-2. b.  A  "reference  copy"  will  be  sent  to  Pritsker  & 
Associates  which  will  be  a  copy  of  the  original  in  the  same  con¬ 
dition  (unpunched,  unbound,  clean,  no  holes,  staples,  etc.).  For  reports 
authored  by  Pritsker  &  Associates ,  the  reference  and  original  copies 
may  be  the  same. 


1-2. c.  Sufficient  copies  for  distribution  will  be 
sent  to  Pritsker  &  Associates  with  prepared  covers.  They  will  be 
drilled  or  punched  (excluding  the  reference  copy)  for  the  appro¬ 
priate  binding  but  will  be  unbound. and  collated.  This  includes  the 
copies  to  be  distributed  to  the  author(s).  Pritsker  &  Associates 
will  supply  the  bindings  and/or  notebooks .  Do  not  three-hole  punch 
the  prepared  covers  for  reports  over  one  inch  thick. 

1-2. d.  Pritsker  &  Associates  will  bind  the  copies  and 
ship  them  to  the  recipients. 

1-2. e.  When  final  versions  of  MOPADS  documents  are 
to  be  submitted  to  the  Army  or  whenever  the  Army  requests ,  camera- 
ready  copies  will  be  prepared  from  the  originals . 


2-0  SUBMISSION  OF  CHANGES. 

When  changes  are  made  tc  drafts ,  those  pages  which  are  changed 
will  be  distributed  to  all  recipients  of  the  document.  Distribution 
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and  binding  requirements  will  be  the  same  as  in  Section  1-0 
above.  If  the  report  was  distributed  copied  on  both  sides  of 
the  paper,  changed  pages  must  be  similarly  copied  so  one-for-one 
replacement  is  possible .  Changed  pages  will  contain  no  annotation 
to  indicate  that  changes  have  been  made. 

Inserted  pages  will  be  numbered  fractionally  (e.g.,  VT-2.1, 
V-2.2,  etc.).  Deleted  pages  will  be  denoted  by  multiple  page 
references  on  the  preceding  page  (e.g.,  "III-2  to  III-U"  to  indicate 
that  pages  III-3  and  III-U  have  been  deleted) . 

Packets  of  changed  pages  will  be  accompanied  by  a  Change 
Notice  form  shown  in  Figure  IV-1.  Copies  for  local  reproduction 
are  contained  in  Appendix  B. 

Recipients  of  changes  will  insert/delete  pages  from  their 
reports  and  file  the  Change  Notice  in  the  Change  Notice  section. 
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CHANGE 
No.  01 


MOPADS  Volume  U.2 
Date:  3/15/1982 


FORTRAN  Style  and  Documentation  Requirements 
for  MOPADS 

•  Operator  and  Non-Operator  Software 
Contract  ARI  Field  Unit,  MDA903-81-C-AA06 

MOPADS  Volume  k.2 ,  dated  February  28,  1982,  is  changed  as  follows: 
1.  Remove  old  pages  and  insert  new  pages  as  indicated  below. 


Remove  Pages  Insert  Pages 

v,vi  v,vi 

II-3  II-3 

IV--3  (this  form) 


2.  File  this  change  sheet  in  the  back  of  the  publication  under 
Change  Notices. 

Figure  IV-1.  Sample  Change  Notice  Form. 
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CHANGE 

Ho.  1 


MOPADS  Volume  5.8  DF 
Date:  August  16,  1982 


Contract  ARI  Field  Unit,  MDA903-8l-C-AA06 


1.  Remove  old  pages  and  insert  new  pages  as  indicated  "below. 


Remove  Pages 

i 

11-5,6 

11-9,10 

IH-3,4 


Insert  Pages 

11-5,6 

II- 9,10 

III- 3,4 


2.  File  this  change  sheet  in  the  hack  of  the  publication  under 
Change  Notices. 

I 
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APPENDIX  A 


The  following  pages  contain  the  Standard  MOPADS  Terminology 
which  will  he  used  in  the  MOPADS  documents.  These  pages  are  to 
be  placed  following  the  Abbreviations  section  in  the  reports. 
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STANDARD  MOPADS  TERMINOLOGY 
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AIR  DEFENSE  SYSTEM 

A  component  of  Air  Defense  which  includes  equipment  and 
operators  and  for  which  technical  and  tactical  training 
are  required.  Examples  are  IHAWK  and  the  AN/TSQ-73. 

AIR  DEFENSE  SYSTEM  MODULE 

Models  of  operator  actions  and  equipment  characteristics 
for  Air  Defense  Systems  in  the  MOPADS  software.  These 
models  are  prepared  with  the  oAINT  simulation  language. 

Air  Defense  System  Modules  include  the  SAINT  model  and 
all  data  needed  to  completely  define  task  element  time, 
task  sequencing  requirements , and  human  factors  influences. 

AIR  SCENARIO 

A  spatial  and  temporal  record  of  aerial  activities  and 
characteristics  of  an  air  defense  battle.  The  Air  Scenario 
includes  aircraft  tracks,  safe  corridors,  ECM,  and  other 
aircraft  and  airspace  data.  See  also  Tactical  Scenario. 

BRANCHING 

A  term  used  in  the  SAINT  simulation  language  to  mean  the 
process  by  which  TASK  nodes  are  sequenced.  At  the  comple¬ 
tion  of  the  simulated  activity  at  a  TASK  node,  the  Branching 
from  that  node  determines  which  TASK  nodes  will  be  simulated 
next . 

DATA  BASE  CONTROL  SYSTEM 

That  part  of  the  MOPADS  software  which  performs  all  direct 
communication  with  the  MOPADS  Data  Base.  All  information 
transfer  to  and  from  the  data  base  is  performed  by  invoking 
the  subprograms  which  make  up  the  Data  Base  Control  System. 

DATA  SOURCE  SPECIALIST 

A  specialist  in  obtaining  and  interpreting  Army  documentation 
and  other  data  needed  to  prepare  Air  Defense  System  Modules. 

ENVIRONMENTAL  STATE  VARIABLE 

An  element  of  ar.  Environmental  State  Vector. 
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ENVIRONMENTAL  STATE  VECTOR 


An  array  of  values  representing  conditions  or  characteristics 
that  »ay  affect  more  than  one  operator.  Elements  of  Environ¬ 
mental  State  Vectors  may  change  dynamically  during  a  MOFADS 
simulation  to  represent  changes  in  the  environment  conditions. 

MODERATOR  FUNCTION 

A  mathematical/logical  relationship  vhich  alters  the  nominal 
time  to  perform  an  operator  activity  (usually  a  Task  Element). 
The  nominal  time  is  changed  to  represent  the  operator’s  capa¬ 
bility  to  perform  the  activity  based  on  the  Operator's  State 
Vector. 

MOPADS  DATA  BASE 

A  computerized  data  base  designed  specifically  to  support  the 
MOPADS  software.  The  MOPADS  Data  Base  contains  Simulation  Data 
Set(s).  It  communicates  interactively  with  MOPADS  Users  during 
pre-  and  post-run  data  specification  and  dynamically  with  the 
SAINT  software  during  simulations. 

MOPADS  MODELER 

An  analyst  who  will  develop  Air  Defense  System  Modules  and 
modify /develop  the  MOPADS  software  system. 

MOPADS  USER 

An  analyst  who  will  design  and  conduct  simulation  experiments 
with  the  MOPADS  software. 

MSAINT  (MOPADS/SAINT) 

The  variant  of  SAINT  used  in  the  MOPADS  system.  The  standard 
version  of  SAINT  has  been  modified  for  MOPADS  to  permit  share¬ 
able  subnetworks  and  more  sophisticated  interrupts.  The  terms 
SAINT  and  MSAINT  are  used  interchangeably  when  no  confusion 
will  result.  See  also,  SAINT. 

OPERATOR  STATE  VARIABLE 

One  element  of  an  Operator  State  Vector. 

OPERATOR  STATE  VECTOR 

An  array  of  values  representing  the  condition  and  character¬ 
istics  of  an  operator  of  an  Air  Defense  System.  Many  values 
of  the  Operator  State  Vector  will  change  dynamically  during 
the  course  of  a  MOPADS  simulation  to  represent  changes  in 
operator  condition. 
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OPERATOR  TASK 


An  operator  activity  identified  on  Directorate  of  Training 
Development  (DTD)  "critical  te-ik  lists*  or  analogous  docu¬ 
mentation  for  Air  Defense  Systems. 

SAINT 

The  underlying  computer  simulation  language  used  to  model  Air 
Deferae  Systems  in  Air  Defense  System  Modules.  SAINT  ia  an 
acronym  for  Systms  Analysis  of  Integrated  Networks  of  Tasks. 
It  is  a  well  documented  language  designed  specifically  to 
represent  human  factors  aspects  of  man/machine  systems.  See 
also  MSAINT. 

SIMULATION  DATA  SET 

The  Tactical  Scenario  plus  all  required  simulation  initiali¬ 
zation  and  other  experimental  data  needed  to  perform  a  MOPADS 
simulation. 

SIMULATION  STATE 

At  «uiy  instant  in  time  of  a  MOPADS  simulation  the  Simulation 
State  is  the  set  of  values  of  all  variables  in  the  MOPADS 
software  and  the  MOPADS  Data  Ease . 

SYSTEM  MODULES 

See  Air  Defense  System  Modules. 

TACTICAL  SCENARIO 

The  Air  Scenario  plus  specification  of  critical  assets  and 
the  air  defense  configuration  (number,  type  and  location  of 
weapons  and  the  command  and  control  system). 

TACTICAL  SCENARIO  COMPONENT 

An  element,  of  a  Tactical  Scenario,  e.g.,  if  a  Tactical  Scenario 
contains  several  Q-73’s,  each  one  is  a  Tactical  Scenario  Com¬ 
ponent. 


TASK 


See  Operator  Task 
TASK  ELEMENTS 


Individual  operator  actions  which,  when  grouped  appropriately, 
make  up  operator  tasks.  Task  elements  are  usually  represented 
by  single  SAINT  TASK  nodes  in  Air  Defense  System  Modules. 
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TASK  BODE 


A  modeling  symbol  used  in  the  SAINT  simulation  language.  A 
TASK  node  represents  an  activity;  depending  upon  the  modeling 
circumstances ,  a  TASK  node  may  represent  an  individual  activity 
such  as  a  Task  Element,  or  it  may  represent  an  aggregated 
activity  such  as  an  entire  Operator  Task. 

TASK  SEQUENCING  MODERATOR  FUNCTION 

A  K  '.kematical/logical  relationship  vhich  selects  the  next 
Operator  Task  vhich  an  operator  will  perform.  The  selection  is 
based  upon  operator  goal  seeking  characteristics. 
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Standard  MOPADS  Terminology 


AIR  DEFENSE  SYSTEM  A  component  of  Air  Defense  which  includes 

equipment  and  operators  and  for  which  techni¬ 
cal  and  tactical  training  are  required. 
Examples  are  I HAWK  and  the  AN/TSQ-73. 


Models  of  operator  actions  and  equipment 
characteristics  for  Air  Defense  Systems  in 
the  MOPADS  software.  These  models  are  pre¬ 
pared  with  the  SAINT  simulation  language. 

Air  Defense  System  Modules  include  the  SAINT 
model  and  all  data  needed  to  completely 
define  task  element  time,  task  sequencing 
requirements,  and  human  factors  influences. 


AIR  SCENARIO  A  spatial  and  temporal  record  of  aerial 

activities  and  characteristics  of  an  air 
defense  battle.  The  Air  Scenario  includes 
aircraft  tracks,  safe  corridors,  ECM,  and 
other  aircraft  and  airspace  data.  See  also 
Tactical  Scenario. 


BRANCHING  A  term  used  in  the  SAINT  simulation  language 

tc  mean  the  process  by  which  TAS'£  nodes  are 
sequenced.  At  the  completion  of  the  simulated 
activity  at  a  TASK  node,  the  Branching  from 
that  node  determines  which  TASK  nodes  will  be 
simulated  next. 


That  part  of  the  MOPADS  software  which  performs 
all  direct  communication  with  the  MOPADS  Data 
Base.  All  information  transfer  to  and  from 
the  data  base  is  performed  by  invoking  the  sub¬ 
programs  which  make  up  the  Data  Base  Control 
System. 


DATA  SOURCE  A  specialist  in  obtaining  and  interpreting 

SPECIALIST  Army  do  cumentatior.  and  other  data  needed  to 

prepare  Air  Defense  System  Modules. 


ENVIRONMENTAL  An  element  of  an  Environmental  State  Vector. 


STATE  VARIABLE 


DATA  BASE  CONTROL 
SYSTEM 


AIR  DEFENSE  SYSTEM 
MODULE 
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ENVIRONMENTAL 

STATE  VECTOR 

An  array  of  values  representing  conditions  or 
characteristics  that  may  affect  more  than  one 
operator.  Elements  of  Environmental  State 
Vectors  may  change  dynamically  during  a  MOPADS 
simulation  to  represent  changes  in  the  environ¬ 
ment  conditions. 

MODERATOR  FUNCTION 

A  mathematical/logical  relationship  which 
alters  the  nominal  time  to  perform  an  operator 
activity  (usually  a  Task  Element).  The  nominal 
time  is  changed  to  represent  the  operator's 
capability  to  perform  the  activity  based  on  the 
Operator's  State  Vector. 

MOPADS  DATA  BASE 

A  computerized  data  base  designed  specifically 
to  support  the  MOPADS  software.  The  MOPADS 

Data  Base  contains  Simulation  Data  Set(s).  It 
communicates  interactively  with  MOPADS  Users 
during  pre-  and  post-run  data  specification  and 
dynamically  with  the  SAINT  software  during 
simulation. 

MOPADS  MODELER 

An  analyst  who  will  develop  Air  Defense  System 
Modules  and  modify /develop  the  MOPADS  software 
system. 

MOPADS  USER 

An  analyst  who  will  design  and  conduct  simu¬ 
lation  experiments  with  the  MOPADS  software. 

MSAI NT (MOPADS/ SAINT) 

The  variant  of  SAINT  used  in  the  MOPADS  system. 
The  standard  version  of  SAINT'  has  been  modified 
for  MOPADS  to  permit  shareable  subnetworks  and 
more  sophisticated  interrupts.  The  terms  SAINT 
and  MSAINT  are  used  interchangeably  when  no 
confusion  will  result.  See  also,  SAINT. 

OPERATOR  STATE 

VARIABLE 

One  element  of  an  Operator  State  Vector. 

OPERATOR  STATE 

VECTOR 

An  array  of  values  representing  the  condition 
and  characteristics  of  an  operator  of  an  Air 
Defense  System.  Many  values  of  the  Operator 
State  Vector  will  change  dynamically  during 
the  course  of  a  MOPADS  simulation  to  represent 
changes  in  operator  condition. 

OPERATOR  TASK 


An  operator  activity  identified  on  Directorate 
of  Training  Development  (DTD)  "critical  task 
lists"  or  analogous  documentation  for  Air 
Defense  Systems. 


SAINT 


SIMULATION  DATA  SET 


The  underlying  computer  simulation  language 
used  to  model  Air  Defense  Systems  in  Air 
Defense  System  Modules.  SAINT  is  an  acronym 
for  Systems  Analysis  of  Integrated  Networks  of 
Tasks.  It  is  a  veil  documented  language  designed 
specifically  to  represent  human  factors  aspects 
of  man/machine  systems.  See  also  MSAIinf. 


t  1  I 

The  Tactical  Scenario  plus  all  required J simu¬ 
lation  initialization  and  other  experimental 
data  needed  to  perform  a  MOPADS  simulation. 


SIMULATION  STATE  At  any  instant  in  time  of  a  MOPADS  simulation 

the  Simulation  State  is  the  set  of  values  of  all 
variables  in  the  MOPADS  software  and  the  MOPADS 
Data  Base. 


SYSTEM  MODULES  See  Air  Defense  System  Modules  - 


TACTICAL  SCENARIO 

9 

The  Air  Scenario  plus  specification  of  critical 
assets  and  the  air  defense  configuration 
(number,  type  and  location  of  weapons  and  the 
command  and  control  system).  . 

TACTICAL  SCENARIO 
COMPONENT 

An  element  of  a  Tactical  Scenario,  e.g.1,  if  a 
Tactical  Scenario  contains  several  Q-73's,  each 
one  is  a  Tactics!  Scenario  Component. 

TASK 

See  Operator  Task. 

Individual  operator  actions  which,  when  grouped 
appropriately,  make  up  operator  tasks.  Task 
elements  are  usually  represented  by  single 
SAINT  TASK  nodes  in  Air  Defense  System  Modules. 


TASK  ELEMENTS 


TASK  NODE 


A  modeling  symbol  used  in  the  SAINT  simulation 
language.  A  TASK  node  represents  an  activity; 
depending  upon  the  modeling  circumstances,  a 
TASK  node  may  represent  an  individual  activity 
such  as  a  Tank  Flement,  or  it  may  represent  an 
aggregated  actlt ity  such  as  an  entire  Operator 
Task. 


TASK  SEQUENCING  A  mathematical/logical  relationship  which 

MODERATOR  FUNCTION  selects  the  next  Operator  Task  which  an 

operator  will  perform.  The  selection  is  based 
upon  operator  goal  seeking  characteristics. 
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APPENDIX  B 


This  section  contains  blank  forms  which  may  be  locally 
reproduced. 
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TERMINOLOGY 


1-0  STANDARD  MOPADS  TERMINOLOGY. 

AIR  DEFENSE  SYSTEM  A  component  of  Air  Defense  which  includes 

equipment  and  operators  and  for  which  techni¬ 
cal  and  tactical  training  are  required. 

Examples  are  I HAWK  and  the  AN/TSQ-73. 

AIR  DEFENSE  SYSTEM  Models  of  operator  actions  and  equipment 

MODULE  characteristics  for  Air  Defease  Systems  in 

the  MOPADS  software.  These  models  are  pre¬ 
pared  with  the  SAINT  simulation  language. 

Air  Defense  System  Modules  include  the  SAINT 
model  and  all  data  needed  to  completely 
define  task  element  time,  task  sequencing 
requirements,  and  human  factors  influences. 

AIR  SCENARIO  A  spatial  and  temporal  record  of  aerial 

activities  and  characteristics  of  an  air 
defense  "battle.  The  Air  Scenario  includes 
aircraft  tracks,  safe  corridors,  ECM,  and 
other  aircraft  and  airspace  data.  See  also 
Tactical  Scenario. 

BRANCHING  A  term  used  in  the  SAINT  simulation  language 

to  mean  the  process  by  which  TASK  nodes  are 
sequenced.  At  the  completion  of  the  simulated 
activity  at  a  TASK  node,  the  Branching  from 
that  node  determines  which  TASK  nodes  will  be 
simulated  next. 

DATA  BASE  CONTROL  That  part  of  the  MOPADS  software  which  performs 

SYSTEM  all  direct  communication  with  the  MOPADS  Data 

Base.  All  information  transfer  to  and  from  . 
the  data  base  is  performed  by  invoking  the  sub¬ 
programs  which  make  up  the  Data  Base  Control 
System. 

DATA  SOURCE  A  specialist  in  obtaining  and  interpreting 

SPECIALIST  Army  documentation  and  other  data  needed  to 

prepare  Air  Defense  System  Modules. 

ENVIRONMENTAL  An  element  of  an  Environmental  State  Vector. 

STATE  VARIABLE 


ENVIRONMENTAL 

STATE  VECT0R 

An  array  of  values  representing  conditions  or 
characteristics  that  may  affect  more  than  one 
operator.  Elements  of  Environmental  State 
Vectors  may  change  dynamically  during  &  MOPADS 
a  insulation  to  represent  changes  in  the  environ¬ 
ment  conditions. 

MODERATOR  FUNCTION 

A  mathematical/logical  relationship  which 
alters  the  nominal  time  to  perform  an  operator 
activity  (usually  a  Task  Element).  The  nominal 
time  is  changed  to  represent  the  operator's 
capability  to  perform  the  activity  based  on  the 
Operator’s  State  Vector. 

MOPADS  DATA  BASE 

A  computerized  data  base  designed  specifically 
to  support  the  MOPADS  software.  The  MOPADS 

Data  Base  contains  Simulation  Data  Set(s).  It 
commmicates  interactively  with  MOPADS  Users 
during  pre-  and  post-run  data  specification  and 
dynamically  with  the  SAH1T  software  during 
simulation. 

MOPADS  MODELER 

An  analyst  who  will  develop  Air  Defense  System 
Modules  and  modify /develop  the  MOPADS  software 
system. 

MOPADS  USER 

An  analyst  who  will  design  and  conduct  simu¬ 
lation  experiments  with  the  MOPADS  software. 

MSAI NT ( MOPADS/SAI NT ) 

The  variant  of  SAINT  used  in  the  MOPADS  system. 
The  standard  version  of  SAINT  has  been  modified 
for  MOPADS  to  permit  shareable  subnetworks  and 
more  sophisticated  interrupts.  The  terms  SAINT 
and  MSAIKT  are  used  interchangeably  when  no 
confusion  will  result.  See  also,  SAINT. 

OPERATOR  STATE 
VARIABLE 

One  element  of  an  Operator  State  Vector. 

An  array  of  values  representing  the  condition 
and  characteristics  of  an  operator  of  an  Air 
Defense  System.  Many  values  of  the  Operator 
State  Vector  will  change  dynamically  during 
the  course  of  a  MOPADS  simulation  to  represent 
changes  in  operator  condition. 


OPERATOR  STATE 
VECTOR 


OPERATOR  TASK  An  operator  activity  identified  during 

weapons  system  front-end  analyses. 


SAINT  The  underlying  computer  simulation  language 

used  to  model  Air  Defense  Systems  in  Air 
Defense  System  Modules.  SAINT  is  an  acronym 
for  Systems  Analysis  of  Integrated  Networks  of 
Tasks.  It  is  a  veil  documented  language  designed 
specifically  to  represent  human  factors  aspects 
of  man /machine  systems.  See  also  MSAU7T. 


SIMULATION  DATA  SET  The  Tactical  Scenario  plus  an  required  simu 

lation  initialization  and  other  experimental 
data  needed  to  perform  a  MOPADS  simulation. 


SIMULATION  STATE  At  any  instant  in  time  of  a  MOPATS  simulation 

the  Simulation  State  is  the  Bet  of  values  of  all 
variables  in  the  MOPADS  software  and  the  MOPADS 
Data  Bose. 


SYSTEM  MODULES  See  Air  Defense  System  Modules. 


TACTICAL  SCENARIO  The  Air  Scenario  plus  specification  of  critical 

assets  and  the  air  defense  configuration 
(number,  type  and  location  of  veapoos  and  the 
command  and  control  system) . 


TACTICAL  SCENARIO  An  element  of  a  Tactical  Scenario,’  e.g.,  if  a 

COMPONENT  Tactical  Scenario  contains  several  Q-73's,  each 

one  is  a  Tactical  Scenario  Component. 


TASK 


See  Operator  Task. 


TASK  ELEMENTS  Individual  operator  actions  which,  when  grouped 

appropriately,  make  up  operator  tasks.  Task 
elements  are  usually  represented  "by  single 
SAINT  TASK  nodes  in  Air  Defense  System  Modules. 
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TASK  fiCDE 


A  modeling  symbol  used  in  the  SAUJT  simulation 
language.  A  TASK  node  represents  an  activity; 
depending  upon  the  modeling  circumstances,  a 
TASK  node  may  represent  an  individual  activity 
such  as  a  Task  Element,  or  it  may  represent  an 
aggregated  activity  such  as  an  entire  Operator 
Task. 


A  mathematical/logical  relationship  vbich 
selects  the  next  Operator  Task  vhicb  an 
operator  will  perform.  The  selection  is  based 
upon  operator  goal  seeking  characteristics. 


TASK  SEQUENCING 
MODERATOR  FUNCTION 


I.  PURPOSE 


This  documert  describes  a  collection  of  utility  programs 
used  by  the  MOPADS  software.  Each  of  the  major  nodules  has 
similar  needs  for  performing  routine  operations  such  as  array 
copying,  initialization,  simple  input  and  output,  and  file 
opening  and  closing.  Also,  there  are  several  functions  rela¬ 
tively  specific  to  MOPADS  such  as  certain  geometric  calculations 
and  encouing/decoding  of  operator  information  that  are  also 
performed  by  more  than  one  module.  In  keeping  with  the  nodular 
design  approach  of  MOPADS,  these  functions  have  been  collected 
into  a  separate  module  and  documented  separately  here. 
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II.  DATA  STRUCTURE  DESCRIPTION 


Since  UTIL  is  a  collection  of  more  or  less  unrelated  pre- 
grams  it  has  no  major  internal  data  structure.  The  single 
exception  to  this  is  a  set  of  programs  that  perform  encoding 
and  decoding  of  characters  to  numbers  and  vice  versa  (see  LK)5U 
and  CPOSU  in  Section  V),.  A  single  array  containing  these  corres¬ 
pondences  is  contained  in  a  COMMON  block  described  in  Section  VIII. 

For  all  other  subprograms  in  UTIL,  the  required  data  is 
passed  as  formal  parameters . 
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III.  OVERVIEW  OF  THE  FLOW  OF  CONTROL 


As  &  general  rule,  the  programs  of  UTIL  are  at  the  lowest 
level  of  processing.  In  other  words,  they  call  only  other 
routines  in  UTIL  or  implicit  FORTRAN  functions.  Some  I/O  pro¬ 
grams,  however,  call  programs  in  the  FFIN2  module  (Polito). 
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IV.  EXTERNAL  FILE  USAGE 


In  every  case  where  a  UTIL  program  must  perform  operations 
with  external  files,  the  unit  number  (and/or  the  file  name)  is 
passed  to  the  program  as  a  formal  parameter.  With  the  exception 
of  Subroutines  OPEHSU  and  OPENDU  (whose  functions  are  to  open 
files),  the  UTIL  programs  assume  that  an  appropriate  file  has 
been  correctly  associated  with  the  unit  number  by  the  calling 
module.  The  UTIL  programs  do  no  error  checking  on  the  files. 
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V.  SUBPROGRAM  DESCRIPTIONS 


The  MOPADS  assigned  suffix  for  UTIL  is  the  letter  "U". 
All  subprograms,  COMMON  block  labels,  and  variables  in  COMMON 
end  with  this  letter. 


BLOCK  DATA  BLOCKU 


C 

C**MODUl£:  MOPADS/UTIL 
PREFERENCE:  HOPADS  VOLUME  5.9 
C 


LOGICAL  FUNCTION  CEQVU  (CHR, CREF) 


C**HODULE:  HOPADS/UTIL 
PREFERENCE:  HOPADS  VOLUME  5.9 
C 

PPURPOSE:  THIS  FUNCTION  IS  USED  TO  DETERMINE  IF  A  CHARACTER  IS 
C  EQUAL  TO  A  REFERENCE  CHARACTER. 

C 

C**INPUT  PARAMETERS:  CHR=CHARACTER  TO  BE  COHPAREB  AGAINST  SOME 

REFERENCE  CHARACTER  TO  SEE  IF  THEY  ARE 
EQUIVALENT 

CREF=REFERENCE  CHARACTER 


C 
C 

c 
c 

POUTPUT  PARAMETERS:  CEQVU=. FALSE.  IF  CHR  DOES  NOT  EQUAL  CREF 


=.TRUE.  IF  CHR  EQUALS  CREF 


SUBROUTINE  COPYCU  (CARAY1 ,N,CARAY2) 


PMODULE:  MOPADS/UTIL 
PREFERENCE:  HOPADS  VOLUME  5.9 
C 

PPURPOSE:  THIS  SUBROUTINE  C0FIE3  THE  CONTENTS  OF  THE  CHARACTER  APRAY 
C  CARAY1  TO  THE  CHARACTER  ARRAY  CARAT?. 

C  j; , 

C++ 3 N F' U T  PARAMETERS:  CARAY1 =THE  CHARACTER  ARRAY  TO  BE  COPIED  INTO 
C  CARAY2 

C  N=THE  DIMENSION  OR  LENGTH  0^  ARRAYS  CARAY1  AND 

C  CARAY2 

C 

POUTPUT  PARAMETERS:  CARAY2=THE  CHARACTER  ARRAY  COPIED  FROM  CARAY1 
C 


SUBROUTINE  CGFYIU  (1ARAY1 ,N,1ARAY2) 


C 

PMODULE:  HOPADS/UTIL 
C*+REF£R£NCE:  HOPADS  VOLUME  5.9 

C 

PPURPOSE:  THIS  SUBROUTINE  COPIES  THE  CONTENTS  OF  THE  INTEGER  ARRAY 
C  IARAY1  TO  THE  INTEGER  ARRAY  IARAY2. 

C 

C**INPUT  PARAMETERS:  IARAY1=THE  INTEGER  ARRAY  70  BE  COPIED  INTO 

C  IARAY2 

C  N=THE  DIMENSION  OR  LENGTH  OF  ARRAYS  1ARAY1  AND 

C  IARAY2 

C 

POUTPUT  PARAMETERS:  IARAY2=THE  INTEGER  ARRAY  COPIED  FROM  1ARAY1 
C 


SUBROUTINE  COPYRU  <RARAY1 ,N, RARAY2) 
C 

PMODULE  MOPADS/UTIL 
PREFERENCE:  HOPADS  VOLUHE  5.9 
C 


PPURPOSE:  THIS  SUBROUTINE  COPicS  THE  CONTENTS  OF  THE  REAL  ARRAY 
C  RARAY1  TO  THE  REAL  ARRAY  RARAY2. 


PINPUT  PARAMETERS: 

C 

C 

C 

POUTPUT  PARAMETERS: 
C 


RARAY1 =THE  REAL  ARRAY  TO  BE  COPIED  INTO  RARAY2 
N=THE  DIMENSION  OR  LENGTH  OF  THE  ARRAYS  RARAT1 
AND  RARAY2 

RARAY2=THE  REAL  ARRAY  COPIED  FROM  RARAY1 


CHARACTERS  FUNCTION  CPOSU  (LPOS) 

C 

C**HODULE:  MOPADS/UTIL 
PREFERENCE:  HOPADS  VOLUME  5.9 

C 

PPURPOSE:  THIS  FUNCTION  IS  USED  TO  CONVERT  A  TUO  DIGIT  INTEGER 
C  CODE  VALUE, LPOS, INTO  ITS  ONE  CHARACTER  ALPHANUMERIC 

C  EQUIVALENT. 

C 

PINPUT  PARAMETERS:  LPOS  =  INTE;GER  VALUE  TO  BE  DECODED 
C 


(•♦OUTPUT  PARAMETERS: 
C 

c 

c 

c 


CPOPU*'  '  IF  LPOS.LL OR  LP0S.GT.36,ELSE 

■ALPHANUMERIC  CHARACTER  ER 'JVALENT  OF  LPOS 
WHERE  1-26  REPRESENT  A- 7  AND  27-34 
9-9 


FUNCTION  EXSMU  TA‘ ,X1 ,C2,X2> 

C 

C**MODULE:  HOPADS/UTIL 
C**REFERENCE:  MOPADS  VOLUME  5.9 
C 

(••PURPOSE:  THIS  FUNCTION  RETURNS  THE  SMOOTHED  VALUE 
C  FOR  TUO  DATA  POINTS. 

C 

C»»INPiiT  PARAMETERS:  A1 ‘SMOOTHING  CONSTANT  FOR  XT 

C  X!>DATA  POINT 

C  A2»SH00THING  CONST AM’  FOR  X2 

C  X2-DATA  POINT 

C 

(••OUTPUT  PARAMETERS:  EXSMU*SMOOTHED  VALUE  RETURNED 
( 


SUBROUTINE  FSPU(Hfi£,MCOL,ICODE> 


(•♦PURPOSE:  FSPU  WILL  EXAMINE  LINE  TO  DETERMINE  IF  IT 
C  IS  THE  FIRST  OR  LAST  STATEMENT  OF  A  FORTRAN  PROGRAM 

(  UNIT  OR  A  NEW  LAMP  DECK  OR  COMDECK. 

C  FSPU  CHANGES  THE  SEPARATORS  AND  THE  LINE  TERMINATOR 

C  CHARACTER  FOR  THE  FFIN2  PROGRAMS.  THESE  CHANGES  ARE 

C  NOT  REVERSED  IT  FSPU. 

C 

(••INPUT  PARAMETERS:  LINE-CHARACTER  VARIABLE  CONTAINING  A  FORTRAN 
C  STATEMENT 

C  NCOL-THE  NUMBER  OF  CHARACTER  POSITIONS  IN  LINE 

C**OUTPUT  PARAMETERS:  IC0CE-9UTPUT  CODE 
C  -1-END  STATEMENT 

C  4-NOT  A  NEU  PROGRAM  UNIT,  LAMP  DECK, 

C  OR  END  STATEMENT 

C  l-"PROGRAN* 

C  2--SUBR0UTINE- 

C  3--FUNCT10N*  TALL  TTPES) 

K  4--DLCCK  DATA*1 

C  5-“*9ECK“ 

C  *-"*COHDEC<" 

C 


C-- STATEMENTS  THAT  START  A  NEU  PROGRAM  UNIT  BUST  HAVE.  BLANKS  OR 
C  "C  AS  SEPARATORS. 

C  *  ■BLOCK  BATA-  NOT  "BLOCKDATA* 

C  "FUNCTION  ONi."  NOT  FUNCTIONONE* 

C 


SUBROUTINE  HEADNU  (POS1 ,P032,HDN,D1 ,B2) 
C 


C**«ODULEs  HOPADS/UTIL 
C*«REFER£NC£*  HOPAOS  VOLUME  5.9 
C 

(•‘PURPOSE*  THIS  SUBROUTINE  IS  USED  TO  CALCULATE  THE  COMPASS  AZIMUTH 
C  FROM  POSITION  1  TO  POSITION  2, THE  GROUND  DISTANCE  BETUEEN 

C  THE  TUO  POINTS  (DISTANCE  IGNORING  ALTITUDE), AND  THE 

C  LINEAR  DISTANCE  (SHORTEST  PATH*  BETUEEN  THE  TUO  POINTS. 

C 


(•♦INPUT  PARAMETERS* 

C 

C 

c 

c 

c 

c 

c 

c 

(•♦OUTPUT  PARAMETERS* 
C 
C 
C 

c 

c 

c 


POS1 (3)*C00RDINATES  POINT  1 

)  «X  COORDINATE  POINT  1  (UNITS-HILCS) 

2  »T  COORDINATE  POINT  1  (UHITS«H1LES) 

3  -2  COORDINATE  POINT  I  (ALTITUDE  IN  FEET) 
P0S2(3)»C0QRDINATES  FOINT  2 

1  -X  COORDINATE  POINT  2  (UMITS«MILES> 

2  «T  COORDINATE  POINT  2  (UNITS-MILES) 

3  »Z  COORDINATE  POINT  2  (ALTITUDE  IN  FEET) 

HDNsCQNPAS5  AZIMUTH  FROM  POS1  TO  POS2— HEADING 
(RADIANS  FROM  NORTH) (‘T  AXIS  IS  NORTH) 

B1 "GROUND  DISTANCE  FROM  POSt  TO  P0S2  (Zl*Z2«0) 
(UNITS*HILESJ 

D2«SHORTEST  DISTANCE  BETWEEN  POST  AND  POS2 
(UNITS*MILES) 


FUNCTION  IBFCU  (LOCN,KEY,NKET,NDEX) 

C 

(•♦MODULE*  HOPADS/UTIL 
(•♦REFERENCE:  MOPADS  VOLUME  5.9 
C 

(•♦PURPOSE*  THIS  FUNCTION  ATTEMPTS  TO  LOCATE  LOCN  AMONG  THE  KEYWORDS  IH 
C  KEY. ONLY  THE  NON-BLANK  PART  OF  LOCN  IS  COMPARED  UITH  THE  LE 

C  CHARACTERS  OF  KEY. THUS  THE  USER  MAY  ABBREVIATE  THE  KEYUORDS 

C 


Q-19 


PINPUT  PARAMETER!*: 

C 

c 

c 

c 

c 

PINPUT/OUTPUf  PAR: 


LOCNsCHAKAC.£R  variable  representing  the  keyuorb 

TO  BE  LOCATED 

KET-CHARAC7ER  ARRAY  OF  KEYUDRDS  TO  BE  SEARCHED 
NKEY'TOTAL  NUr.BER  LF  KETUORDS  IN  KEY  AND  THE 
LEN8TH  OF  THE  JtDEX  ARRAY 

NDcX*INTECER  CROSS  REFERENCE  ARRAY. 1BFCU  USES  A 


C 

c 
c 
c 
c 
c 
c 

C**OUTPUT  PARAMETERS:  IBFCU«-1  -LOCN  AMBIGUOUS 


BINARY  SEARCH  TO  LOCATE  LOCN, BUT  THE  USER 
NEEB  MOT  ARRANGE  KEY  IN  THE  CORRECT 
COLLATTNS  ORDER. ON  THE  FIRS!  CALL, SET 
M£X(l)*a.IBFCU  MILL  COLLATE  KEY  BY  STORING 
THE  CORRECT  INDECES  IN  NDEX.DO  NOT  CHANGE 
NDEX  BETUEEN  CALLS. 


c 

0  -LOCN  NOT 

FOUND  IN  KEY 

c 

C 

I  -LOC*  EQU< 

LS  KEY(I) 

1  1 

1  1 

FUNCTION  IFCU  (LOCN, KEY, NKEYi 
C 

PHODULE:  HOPADS/UTIL 
PREFERENCE:  NOPADS  VOLUME  5.9 


PPURPDSE: 

C 

c 

C 
C 

PINPUT  PARAMETERS: 

C 

c 

c 

PDUTPUT  PARAMETERS: 
C 

c 

c 


THIS  FUNCTION  ATTEMPTS  TO  LOCATE  LOCN  AMONG  THE  KEYUDRDS 
IN  KEY. ONLY  THE  NON-BLANK  PART  OF  LOCN  IS  MATCHED  UITH  THE 
LEFMOST  CHARACTERS  IN  KEY. THUS, THE  USER  HAT  ABREVIATE 
THE  KEYUDRDS. IFCU  USE  A  LINEAR  SEARCH, SEE  ALSO  IBFCU. 

* 

LOCN=THE  KEYWORD  TO  BE  LOCATED  (CHARACTER) 
KEY(NKEY)3AN  ARRAY  OF  KEYUDRDS  TO  SEARCH  FOR 
LOCN  (CHARACTER) 


IFCU»  -1  -  LOCN  AMBIGUOUS 

0  -  LOCN  NO*T  FOUND  IN  KEY 
I  -  LOCN«KEY(I) 


SUBROUTINE  INOIRU  (LU, OPEND,FILEN, ACCS, FORMA, IERR) 

C 

PHODULE:  HOPADS/UTIL 
PREFERENCE:  MOPADS  VOLUME  5.9 
C 

PPURPOSE:  THIS  SUBROUTINE  DETERMINES  THE  CURRENT  STATUS  OF  A 
C  SPECIFIED  UNIT. 
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C*«INPUT  PARAMETERS: 

C 

C 

C**OUTPUT  PARABETERS: 
C 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 


LU«UNIT  RUBBER  FOR  UHICH  THE  STATUS  IS  BEING 
CHEChEL 

0PEND=L0GICAL  VARIABLE  DESIGNATING  UHETHER  OR 
NOT  *  UNIT  NUBPER  iS  CONNECTED  TO  A  FILE 
(*.TRUt.  IS  CONNECTED  TO  A  FILE, =  . FALSE. 
IS  NOT  CONNECTED  TO  A  FILE) 
FlLEN*CHARACT£k  VARIAFLE  REPRESENTING  THE  NABE 
OF  THE  FILE  CONNECTED  TO  THE  UNIT  NUMBER 
ACCS-A  CHARACTER  VARIABLE  INDICATING  THE  ACCESS 
BETHOD  OF  THE  FILE 

FORBA-A  CHARACTER  VARIABLE  INDICATING  UHETHER 
THE  FILE  IS  OPEHED  FOR  FORMATTED  I/O 
OPERATIONS  OR  UNFORMATTED  2/0  OPERATIONS 
1ERR«SYSTEH  ERROR  CODE. EQUALS  ZERO  IF  NO  ERROR 
OCCURS. 


SUBROUTINE  1NSCLU  (N,N,LCOL,BFIRST,IARRAT, JCFILt.IESR) 

C 

C«*BODULE:  HOPADS/UTZL 
^♦REFERENCE:  BOPADS  VOLUBE  S.9 
C 

C*«PURPOSE:  THIS  SUBROUTINE  IS  USED  TO  INSERT  A  COLUMN  OF  VALUES  INTO 
C  AN  ARRAY. THIS  SUBROUTINE  IS  USED  UITH  ARRAYS  THAT  ARE 

C  UTILIZING  A  POINTER  (BFIRST)  THAT  POINTS  TO  THE  NEXT 

C  AVAILABLE  COLUMN  IN  THE  ARRAY  UHERE  VALUES  MAY  BE  LOADED. 

C  BEFORE  THIS  SUBROUTINE  IS  CALLED  I  HE  USER  SHOULD  CALL 

C  SUBROUTINE  SETVU  TO  SET  UP  THE  POINTER  STRUCTURE. 


C*«PURPOSE:  THIS  SUBROUTIf 
C  AN  ARRAY. THIS 

C  UTILIZING  A  PC 

C  AVAILABLE  COLli 

C  BEFORE  THIS  S(1 

C  SUBROUTINE  SET 

C 

t**INPUT  PARAMETERS:  B»NU 
C  N«NU 

C  LCOL 

C 
C 
C 

C— INPUT/OUTPUT  PARAMETERS: 


H>NUNBER  OF  ROUS  IN  IARRAY 
N*NUMBER  OF  COLUMNS  IN  IARRAY 
LC0L(H-1)>VECT0R  OF  VALUES  TO  BE  LOADED  INTO  A 
COLUMN  OF  IARRAY  (NO  VALUE  FOR  ROU  N 
TO  AVOID  DESTROYING  POINTER  SYSTEM) 


NFIRST=FIR$T  AVAILABLE  COLUMN  FOR  STORING  VALUES 
1ARRAY<H,N)*ARRAT  THAT  DILL  HAVE  A  COLUMN  OF 
VALUES  LOADED  INTO  IT. A  -1  U1LL  BE 
LOADED  INTO  ROU  H  OF  THE  COLUMN 
BEING  FILLED, TO  SHOW  THAT  THE  COLUMN 
IS  FILLED. 


C«*OUTPUT  PARAMETERS: 
C 

c 

c 


JCFILL'THE  NUMBER  OF  THE  COLUMN  THAT  HAS  FILLED 
lERR'ERROR  FLAG 
•0  NO  ERROR 

■1  IARRAY  IS  FULL  IMFIRST«0) 


[‘♦OUTPUT  PARAMETERS:  JCFILL*THE  NUMBER  OF  THE  COLUMN  THAT  UA5  FILLED 
C  lERR^EHRQR  FLAS 

c  *0  SO  ERROR 

C  *1  IARRAT  IS  FULL  <MFTRST=0) 

C 


FUNCTION  1SUNU  (IAR?,NA) 

C 

[•♦MOPADS/UTIL 

[♦♦REFERENCE:  HOPADS  VOLUME  3.9 
[♦♦PURPOSE:  TO  SUN  THE  ELEMENTS  OF  AN  ARRAY. 

C 

[♦♦INPUT  PARAMETERS:  IART (HA)-ARRAT  UHOSE  ELEMENTS  ARE  TO  BE  SUMMED 
[ 


SUBROUTINE  LOADCU  <CVALrfl,NtNROU, [ARRAY) 


[♦♦MODULE:  MOPADS/UTIL 
[•♦REFERENCE:  NOPADS  VOLUME  3.9 
C 

[♦♦PURPOSE:  THIS  SUBROUTINE  IS  USES  TO  LOAD  ONE  ROU  OF  A  CHARACTER 
[  ARRAY  [ARRAY  UITH  THE  VALUE  STORED  IN  CVAL. 

[ 

[♦•INPUT  PARAMETERS:  CVAl-THE  CHARACTER  VALUE  TO  BE  LOADED  INTO  CARRAY 

H-NUMBER  OF  ROUS  IN  CARRAY 
N-XUHBER  OF  COLUMNS  IN  CARRAY 
NROU*THE  ROU  OF  CARRAY  TO  BE  LOADED 


C 

c 

c 

c 

[♦♦INPUT/OUTPUT  PAR: 
C 
C 
C 


CARRAT*THE  CHARACTER  ARRAY  TO  BE  LOADED 

PARTIALLY  OR  COMPLETELY. RETURNED  AS 
THE  LOADED  ARRAY. 


SUBROUTINE  LOADIU  (IVAL,H,N,NROU,lARRAY) 

C 

[•♦MODULE:  MOPADS/UTIL 
[♦♦REFERENCE:  MOPAOS  VOLUNE  5.9 
C 

[•♦PURPOSE:  THIS  SUBROUTINE  IS  USEB  TO  LOAB  ONE  ROU  OF  AN  INTEGER 
C  ARRAY  IARRAT  UITH  THE  VALUE  STORED  IN  1VAL. 

C 
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CmINPUT  parameters 

c 

c 


:  I VAL  =  THE  INTEGER  VALUE  TO  BE  LOADED  IN  1 ARRAY 

H=NUMB£R  OF  ROUS  IN  lARkAY 
N=NUHBER  OF  COLUMNS  IN  I  ARRAY 
NR0U*THE  KOU  OF  1ARRAY  TO  BE  LOADED 
C 

C**INPUT/OUTPUT  PAR:  IARRAY=THE  INTEGER  ARRAY  TO  BE  LOADED 
C  PARTIALLY  OR  COMPLETELY. RETURNED  AS 

C  THE  LOADED  ARRAY. 


SUBROUTINE  LOADRU  (ROAL,M,KROU, RARRAY) 


C 

C*+MODULE:  HOPADS/UTIL 
C**REFER£NC£:  NOPADS  VOLUME  3.9 

C 

C**PUHPOSE:  THIS  SUBROUTINE  IS  USED  TO  LOAD  ONE  ROU  OF  AN  REAL  ARRAY 
C  RARRAY  UITH  THE  VALUE  STORED  IN  RVAL. 

C 


C**INP'JT  PARAMETERS: 

C 

C 

c 

c 

C**INPUT/OUTPUT  PAR: 
C 

m 

t. 


RVAL“THE  REAL  VALUE  TO  BE  LOADED  INTO  RARRAY 
(^NUMBER  OF  ROUS  IN  RARRAY 
N«NUHB£R  OF  COLUMNS  IN  RARRAY 
NR0U»THE  ROU  OF  RARRAY  TO  BE  LOADED 

RARRAY=THE  REAL  ARRAY  TO  BE  LOADED 

PARTIALLY  OR  COMPLETELY. RETURNED 
AS  THE  LOADED  ARRAY. 


C 


FUNCTION  LPOSU  (CHR) 

C 

C**HDDULE l  HOPADS/UTIL 
^♦REFERENCE:  HOPADS  VOLUME  5.9 
C 

CMPURPOSE:  THIS  FUNCTION  IS  USED  TO  CODE  ALPHANUMERIC  CHARACTER 
C  INTO  AN  INTEGER  REPRESENTATION  OF  THE  CHARACTER. THE  NUMBERS 

C  1-26  REPRESENT  THE  CHARACTERS  A-Z  AND  THE  NUMBERS  27-36 

C  REPRESENT  THE  CHARACTERS  0-9. 

C 

C»*INPUT  PARAMETERS:  CHR*CHARACTER  STRING  10  BE  CODED  AS  AN  INTEGER 
C 

C**OUTPUT  PARAMETERS:  LPOSU=N  {INTEGER  CODE  VALUE  FOR  THE  CHARACTER 
C  (CHR) 

C 


SUBROUTINE  NBLCU  (STRING, LOi ,102) 


C 

CoMQDULE:  HOPADS/UTIL 
C**REFERENCE:  MOPADS  VOLUME  5.9 
C 

C**PURPOSE:  THIS  SUBROUTINE  RETURNS  THE  FIRST  AND  LAST  NON-BLANK 
C  CHARACTER  POSITIONS  OF  A  STRING. 

C 

COINPUT  PARAMETERS:  STRING=T!!E  STRING  TO  DELINEATE  (CHARACTER) 

C 

C**OUTPUT  PARAMETERS:  L01,L02*THE  POSITION  OF  THE  FIRST  AND  LAST  NON- 
C  BLANK  CHARACTER  IN  STRING. IF  STRING  IS 

C  ALL  CLANK, L01*L02«0 

C 


FUNCTION  NCLIPU  (INCLIP, LOU, IHIGH) 


COMODULE:  HOPADS/UTIL 
PREFERENCE:  HOPADS  VOLUME  5.9 
C 

CopURPOSE:  THIS  FUNCTION  EVALUATES  THE  VARIABLE  INCLIP  TO  DETERMINE 
C  IF  IT  LIES  U1THIN  SOME  SPECIFIED  RANGE  OF  VALUES. IF  IT 

C  IS  LARGER  THAN  THE  UPPER  BOUND, THE  FUNCTION 

C  RETURNS  THE  VALUE  OF  THE  UPPER  BOUND. IF  IT  IS  SMALLER 

C  THAN  THE  LOVER  BOUND  THE  FUNCTION  RETURNS 

C  THE  VALUE  OF  THE  LOUER  BOUND. IF  IT  LIES  UITH1N  THE  RANGE 

C  THE  VALUE  OF  INCLIP  IS  RETURNED. 


COPURPOSE:  THIS  FUN 
C  IF  IT  LI 

C  IS  LARGE 

C  RETURNS 

C  THAN  THE 

C  THE  VALU 

C  THE  VALU 

C 

COINPUT  PARAMETERS: 

C 

C 

C 

C 

C 

C 

COOUTPUT  PARAMETERS: 

C 

C 

c 

c 


INCLIP=VARI ABLE  TO  BE  EVALUATED  ON  THE  RANGE 
FROM  LOU  TO  IHI6H 

L0U»L0UER  BOUND  OH  THE  RANGE  OF  ACCEPTABLE 
VALUES  FOR  INCLIP 

1HI6H=UPPER  BGUND  ON  THE  RANGE  OF  ACCEPTABLE 
VALUES  FOR  1HCLIP 

NCL1PU=VALUE  OF  THE  FUNCTION  RETURNED. IF  INCLIP 
>  IHIGH  THEN  NCLIPU*IH1DH. IF  INCLIP  < 
LOU  THEN  NCLIPU* LOU. OTHERWISE  NCLIPU* 
INCLIP. 


SUBhOUTIHE  OPERDU  (LU,FILEN, STAT,FM,NREC.IERR,*) 


Ci.NPSULE:  niir  AD*I/UTIL 
C**R'EFER£NCE:  HO.' ADS  VOLUME  5.9 

C 

C**!jJRPOSF.:  THIS  SUBROL'T t. VE  OPENS  A  DIRECT  ACCESS  FILE 

C 

C**INPU7  PARAHETC:(S:  LU~I  QGICAL  UNIT  NUMBER  OF  THE  FI!  E  TO  BE  OPENED 
C  F1LEN=A  CHARACTER  EXPRESSION  REPRESENTING  THE 

C  FILE  NAME  TO  BE  OPENED 

C  STAT=A  CHARACTER  EXPRESSION  REPRESENTING  THE 

C  FILE  STATUS  (OLD, NEU, SCRATCH  UNKNGUN/ 

C  FH-A  CHARACTER  EXPRESSION  DESIGNATING  UHETHER 

.  THE  FILE  IS  FORMATTED  OR  UNFQKNAY iED 

C  NREC=RECORD  LENGTH 

C 

C**0'ITPUT  PARAMETERS:  lERR'THE  ERROR  NUHPER  <«0  IF  ECNE  FOUND) 

C 

C**ALTERNATE  RETURNS:  V<E  S-NGLE  ALTERNATE  RETURN  OCCURS  LHtN  IERR 
C  IS  NOT  EQUAL  ZERO. 

C 


SUBROUTINE  OPENSU(LU,FlLEN,STAT,FM,IERR,*) 

c 

C — MODULE  10PADS/UTIL 
^♦REFERENCE:  MOPADS  VOLUME  5.9 
C 

C— PURPOSE:  TO  OPEN  A  SEQUENTIAL  FILE 
C 

C— INPUT  PARAMETERS:  LU-UNIT  NUMBER 

C  FILEN-F1LE  NAME  (CHARACTER  VARIABLE) 

C  STAT-5TATUS  (CHARACTER) 

C  FM-FILE  FORMAT  (CHARACTER) 

C 

C— OUTPUT  PARAMETERS:  IERR-CONDITION  COPE 
C  O-NO  ERROR 

C  .NE. O-SYSTEM  ERROR  CODE 

C 

C— ALTERNATE  RETURNS:  O-NO  ERROR 
C  (-ERROR,  IERR.NE.0 

C 
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SUBROUTINE  PAGEU  (JFL, NLVMAXL, LINES, NPAGE) 

C 

CmHQDULE:  HOPADS/UTIl 
PREFERENCE:  NOPADS  VOLUHE  5.9 


PPURPOSE: 

C 

c 
c 

PINPUT  PARAMETERS: 
C 

c 

c 


THIS  SUBROUTINE  IS  USED  TO  COUNT  THE  NU.-BER  OF  LINES 
PRINTED  ON  A  PAGE  AND  ISSUE  A  PAGE  E-'ECT  IF  NEE3E5.CALL 
PAGEU  BEFORE  UNITING  NL  MURE  LINES  ON  THE  FILE. 


JFL-THE  FILE  NUMBER  (IF  .L£.  C, RETURN  WITH  NO 
ACTION) 

NL-NUHBER  OF  NEU  LINES  TO  BE  ADDEB 
MAXL*HAXIMUM  NUMBER  OF  LINES/PAGE 


C 

C**1NPUT/0UTPUT  PAR: 
C 

c 

c 

c 

c 

c 

c 

c 

c 


LINE*7HE  NUMBER  OF  LINES  OH  A  PAGE  BEFORE  NL 
ARE  PRINTED  (INPUT) 

■THE  NUMBER  OF  LINES  ON  A  PAGE  AFTER  NL  LINES 
ARE  PRINTED  (IF  A  PAGE  EJECT  HAS  BEEN  ISSUED 
LINES  'JILL  EQUAL  NL+2)  (OUTPUT) 

NPAGE=THE  PAGE  NUMBER. PAGEU  U1LL  INCREMENT  THE 

PAGE  NUMBER  AND  PRINT  A  PAGE  INDICATOR  IF  A 
PAGE  EJECT  IS  ISSUED. IF  NPA6E  IS  SENT 
NEGATIVE  THIS  FEATURE  IS  SUPPRESSED 


SUBROUTINE  PRMU(LFD,MSG,NPRNT) 

C 

C--HODULE  HOPADS/UTIL 
PREFERENCE:  MOPADS  VOLUHE  5.9 
C 

C— PURPOSE:  TO  PRINT  A  MESSAGE  ON  A  FILE. 
C 


C— INPUT  PARAMETERS! 

C 

C 

c 

c 

c 

c 

C— EXAMPLES! 

C 
C 


LFD-CONTROL  PART  OF  FORMAT (CHARACTER) 

(E.G.  '//AX')  UP  TO  35  CHARACTERS. 
MSG-MESSAGE  STRING  TO  PRINT (CHARACTER) 
NPRNT-FILE  NUMBER  TO  WRITE  TO.  IF  NPRNT.IE.O 
RETURN  U1TH  NO  PRINTING. 


CALL  PRMUt 'IH1 //5X' , 'THIS  IS  A  MESSAGE', 4) 
CALL  PRMU('I8HMESSAGE»','ANT  STRING  ,6) 
CALL  PRHU('1X,m(1H-) V  '»*> 


ififtll'XJtfi'Ul  A*  KM  Alt  FJI3\*r 


SUBROUTINE  PRNSU(MSG,NP 


RNT.NBC) 


C-  -MODULE  NOPADS/UTIL 
PREFERENCE:  MOPADS  VOLUME  5.9 
C 

C — PURPOSE:  TO  PRINT  A  MESSAGE  ON  A  FILE  UITH  NO  TRAILING 
C  BLANKS. 

C 

C— INPUT  PARAMETERS:  MSG-MESJJaGE  STRING  (CHARACTER) 

C  NPRNT-F1LE  NUMBER.  IF  NPRNT.LE.O, 

C  RETURN  UITH  NO  PRINTING 

[ 

C— OUTPUT  PARAMETERS:  NBC-NUHBER  OF  LAST  NON-BLANK  CHARACTER 
C  IN  MSG. 

C 


SUBROUTINE  PUTCU  (CFkOM.NF, II fNTf C . 0 ) 


PHODULt:  MOPADS/UTIL 
C**REFERENCE:  MOPADS  VOLUME  5.9 
C 

THIS  SUBROUTINE  TRANSFERS  THE  CONTENTS  OF  THE  CHARACTER 
VECTOR  CFROM  TO  THE  CHARACTER  VECTOR  CTO  STARTING  UITH 
THE  II  ELEMENT  OF  CTO. IF  THE  TRANSFER  LEADS  TO  AN  OVERFHiU 
ON  CTO  (TRANSFER  EXCEEDS  DIMENSION  OF  CTO)  THE  OVER; ;  O'J 
VALUES  UILL  NOT  BE  TRANSFERRED  TO  CTO. 


PPURPOSE: 

C 

c 
c 
c 
c 

PINPUT  PARAMETERS: 
C 

c 

c 

c 

c 

c 

PINPUT/3UTFUT  PAR: 
C 

c 

c 

c 


CFRUM*CHARACTER  VECTOR  CONTAINING  VALUES  TO  BE 
TRANSFERED  70  CTO 
NF«NUMBER  OF  ELEMENTS  OF  CFROM 
I1*ELEMENT  NUHEER  OF  CTO  UHERE  THE  TRANSFER  OF 
THE  CONTENTS  OF  CFROM  TO  CTO  HILL  BEGIN 
NT*NUHBER  OF  ELEMENTS  IN  CTO 

CTO=CHARACTER  VECTOR  TO  UHICH  THE  CONTENTS  OF 
CFROM  UILL  BE  TRANSFERRED. RETURNED  AS  THE 
ORIGINAL  VECTOR  UITH  THE  TRANSFFS  MODIFI¬ 
CATIONS  COMPLETED 
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SUBROUTINE  PUTIU  (IFROH,NF , I 1 ,NT , ITO) 
C 

C**MODULE:  MOPADS/UTIL 
C* ^REFERENCE:  HOPADS  VOLUME  5.9 


C**PUftFOSE: 

C 
C 
C 
C 
C 

C*+INPUT  PARAMETERS: 

C 

C 

C 

C 

C 

c 

C**INPUT/OUTPUT  PAR: 

c 

c 

c 

c 


THIS  SUBROUTINE  TRANSFERS  THE  CONTENTS  OF  THE  INTEGER 
VECTOR  IFROM  TO  THE  INTEGER  VECTOR  ITO  STARTING  UITH  THE 
II  WORD  OF  ITO. IF  THE  TRANSFER  LEADS  TO  AN  OVERFLOW  ON  ITO 
(TRANSFER  EXCEEDS  DIMENSION  OF  ITO)  THE  OVERFLOW  VALUES 
UILL  NOT  BE  TRANSFERED  TO  ITO. 


IFROM=INTEGER  VECTOR  CONTAINING  VALUES  TO  BE 
TRANSFERED  TO  ITO 
NF=NUMBER  OF  WORDS  IN  IFROM 

I 1 =UQRD  NUMBER  OF  ITO  WHERE  THE  TRANSFER  OF  THE 
CONTENTS  OF  IFROM  TO  ITO  WILL  BEGIN 
NT=NUHBER  OF  WORDS  IN  ITO 

ITO=INTEGER  VECTOR  TO  UHICH  THE  CONTENTS  OF 
IFROM  WILL  BE  TRANSFERED  TO. RETURNED  AS  THE 
ORIGINAL  VECTOR  UITH  THE  TRANSFER  MODIFI¬ 
CATION  COMPLETED 


SUBROUTINE  PUTRU  (RFROM,NF, It , NT, RTO) 

C 

C**MODULE:  HOPADS/UTIL 
^♦REFERENCE:  HOPADS  VOLUME  5.9 
C 

C**PURPOSE:  THIS  SUBROUTINE  TRANSFERS  THE  CONTENTS  OF  THE  REAL  VECTOR 
C  RFROM  TO  THE  REAL  VECTOR  RTO  STARTING  UITH  THE  II  UORD  OF 

C  RTO.  IF  THE  TRANSFER  LEADS  TO  AN  OVERFLOW  ON  RTO  (TRANSFER 

C  EXCEEDS  DIMENSION  OF  RTO)  THE  OVERFLOU  VALUES  UILL  NOT  BE 

C  TKANSFERRED  TO  RTO. 

C 

C*»INPUT  PARAMETERS:  RFROM=REAL  VECTOR  CONTAINING  VALUES  TRANSFERRED 
C  TO  RTO 

C  NF=NUHBER  OF  WORDS  IN  RFROM 

C  I 1 =U0RD  NUMBER  OF  RTO  WHERE  THE  TRANSFER  OF  THE 

C  CONTENTS  OF  RFROM  TO  RTO  UILL  BEGIN 

C  NT=NUHBER  OF  WORDS  IN  RTO 

C 
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PINPUT/OUTPUT  PAR: 

C 

c 

c 

c 


RTO=REAL  VECTOR  TO  UHICH  THE  CONTENTS  OF  RF.RQM 
UILL  BE  TRANSFERRED  TO. RETURNED  A3  THE 
ORIGINAL  VECTOR  UITH  TRANSFER  MODIFICATIONS 
COMPLETED 


SUBROUTINE  RETRYUUIN, JOUT,*,*> 

C—MODULE:  MOPADS/UTIL 
PREFERENCE:  M0PAD3  VOLUME  5.9 
r-.py^pOSE: 

C  RETRYU  UILL  ASK  IF  THE  USER  WANTS  TO  RE-TRY  WHATEVER 

C  HE  IS  DOING.  IF  YES,  TAKE  ALTERNATE  RETURN  1.  IF  NOT 

C  USE  RETURN  2. 

C 

C— INPUT  PARAMETERS: 

C  JIN-INPUT  FILE  NUMBER 

C  JOUT-OUTPUT  FILE  NUMBER 
C 

C— ALTERNATE  RETURNS 
C  1-YES, RETRY 

C  2-NO,  NO  NOT  RETRY 


SUBROUTINE  RMVCLU  < JCOLN,M,N,HFIRST, IARRAY, IERR) 


C**MODULE:  MOPADS/UTIL 
PREFERENCE:  HOPADS  VOLUME  5.9 
C 

PPURPOSE:  THIS  SUBROUTINE  IS  USED  TO  MAKE  A  COLUMN  OF  AN  ARRAY 
C  AVAILABLE  FOR  LOADING  VALUES  INTO  IT. THIS  SUBROUTINE  IS 

C  USED  UITH  ARRAYS  THAT  ARE  UTILIZING  A  POINTER  CMFIRST) 

C  TO  THE  FIRST  AVAILABLE  COLUMN  IN  THE  ARRAY  UHERE  VALUES 

C  MAY  BE  LOADED.  , 

C  lit 

JCOLN=COLUHN  THAT  IS  TO  BE  MADE  AVAILABLE ' 

M=NUMBER  OF  ROUS  IN  IARRAY 
N*NUHBER  OF  COLUMNS  IN  IARRAY  I 


PINPUT  PARAMETERS: 
C 
C 
C 

PINPUT/DUTPUT  PAR: 

C 

C 

c 

c 

c 

c 

c 


MFIRST=POINTER  TO  THE  FIRST  AVAILABLE  COLUMN  IN 
THE  ARRAY  THAT  A  COLUMN  IS  BEING  MADE 
AVAILABLE  IN. THIS  SUBROUTINE  UPDATES 
THIS  POINTER  UITH  THE  NUMBER  OF  THE 
COLUMN  BEING  REHOVEB  CJCCLN). 
IARRAY(M,N)=ARRAY  IN  UHICH  A  COLUMN  IS  BEING  MADE 
AVAILABLE  FOR  STORING  OTHER  VALUES. 
COLUMN  JCOLN  OF  ROU  M  UILL  BE  UPDATED 


C**OUTPUT  PARAMETERS:  1ERR=ERR0R  FLAB 

C  *1  IF  TRIED  70  HAKE  A  COLIMN  AVAILABLE  THAT 

C  DOES  NOT  EXIST  (COL  I  .GT.  N  ,0R.  COL  «  .IE. 

C  0) 

C  >2  IF  COLUMN  TO  BE  HADE  AVAILABLE  IS  HOT 

C  CURRENTLY  OCCUPIED 

C 


FUNCTION  PSUHU  (RARY,NA) 

C 

C**HODULE:  MOPADS/UTIL 
C**REFERENCE:  MOPADS  VOLUHE  5.? 

C 

CMPURPOSE:  TO  SUH  THE  ELEMENTS  OF  AN  ARRAY. 

C 

CMINPUT  PARAMETERS:  RARY(NA)-ARRAY  UHOSE  ELEMENTS  ARE  TC  BE  SUMMED 
C 


CHARACTERS  FUNCTION  RYNUtJIN, JOUT) 

C — MODULE:  MOPADS/UTIL 
DEREFERENCE:  HOPADS  VOLUME  5.9 
C—PURPOSE: 

C  RYNU  UILL  QUERY  THE  USER  FOR  A  YES  OR  NO  RESPONSE. 
C 

C--INPUT  PARAMETERS: 

C  JIN-INPUT  FILE  NUMBER 
C  JOUT-OUTPUT  FILE  NUMBER 

C 

C — OUIF.T  PARAMETERS: 

C  RYNU- 'T'  FU«  YES 

c  'N'  res  )<0 


JUBR0UT1NE  SETVU  (IN1TV,H,N, IARRAYfHFIRST) 

C 

C**NODULE:  MOPADS/UTIL 
^♦REFERENCE:  MOPADS  VOLUME  5.9 
C 

C=»*PURPOSE:  THIS  SUBROUTINE  IS  USED  TO  INITIALIZE  ALL  THE  ELEMENTS 
C  EXCEPT  ROU  M  OF  IARRAY  TO  SOME  VALUE  (INITV) .THE  NEXT 

C  AVAILABLE  COLUMN  POINTER  IS  SET  UP  IN  ROU  H  AND  MKIRST 

C  (FIRST  AVAILABLE  COLUMN)  IS  INITIALIZED  TO  1 .SEE  SUBROUTINE 

C  INSCLU  AND  SUBROUTINE  RMVCLU. 


c 

t>*lHPUT  PARAMETERS: 

C 

C 

c 

c 

C**INPUT/OUfPllT  PAR: 

C 

C 

c 

c 

c 

c 


1NITV=THE  VALUE  TO  INITIALIZE  ALL  THE  ELEMENTS 
OF  IARRAY  TO 

H*NUMBER  OF  ROUS  IN  IARRAY 
N= NUMBER  OF  COLUMNS  IN  IARRAY 

IARRAY(M,N>=AURAY  TO  BE  INITIALIZED. ROD  H  IS 

WORKING  STORAGE  USED  TO  STORE  POINTER 
TO  THE  NEXT  AVAILABLE  COLUMN  FOR 
STORING  VALUES. 

HFIRST=POINTER  TO  FIRST  AVAILABLE  COLUHN  IN 
IARRAY 


SUBROUTINE  VECU  (ZP0S1  ,ZP0S.?,HDN,D2f  VELMAG,  VEC) 


C*»MODULE:  MOPADS/UTIL 
C**REFERENCE:  MOPADS  VOLUME  5.9 
C 

CMPURPOSE:  THIS  SUBROUTINE  IS  USED  TO  CALCULATE  THE  COHPOHENTS  OF  A 
C  THREE  DIMENSIONAL  (X,Y,Z)  VELOCITY  VECTOR. THIS  SUBROUTINE 

C  USES  OUTPUT  FROM  SUBROUTINE  HFADNU  TO  CALCULATE  THE 

C  COMPONENTS  OF  THE  VELOCITY  VECTOR. 

C 

ZP031*THE  Z  COORDINATE  OF  THE  INITIAL  POSIT. ON 
CTHE  ALTITUDE  MEASURED  IN  FEET) 

ZP0S2eTHE  Z  COORDINATE  OF  THE  FINAL  POSITION  (THE 
ALTITUDE  MEASURED  IN  FEET) 

H8N-C0HPASS  AZIMUTH  FROM  INITIAL  POINT  Tk  FINAL 
POINT  IN  RADIANS  FROM  NORTH. (*Y  AXIS  IS  NORTH 
I2*THE  STRAIGHT  LINE  DISTANCE  FROM  THE  INITIAL 
POSITION  TO  THE  FINAL  POSITION  IN  STATUTE 
MILES 

VELHAGsRAGHITUDE  OF  THE  VELOCITY  VECTOR  (MILES/HR 


C*»INPUT  PARAMETERS: 
C 

c 

c 

c 

c 

c 

c 

c 

c 

c 

C*»OUTPUT  PARAMETERS: 

C 

c 

c 

c 


VEC(3)*THE  COMPONENTS  OF  THE  VELOCITY  VECTOR 
1-X  COMPONENT  (NILES  PER  MINUTE) 

2«Y  COMPONENT  (MILES  PER  MINUTE) 

3*Z  COMPONENT  (FEET  PER  MINUTE) 


Q-31 


Q-32 


VI.  USER  INSTRUCTIONS 


1-0  LOADING  ARRAYS. 

1-1.  Initializing  Arrays. 

Subroutines  LOADCU,  LOADIU,  and  LOADRU  will  initialize 
all  or  part  of  character,  integer,  and  real  arrays,  respectively, 
with  a  single  value.  They  are  written  formally  to  initialize  a 
single  row  of  a  two  dimensional  array.  This  structure,  however, 
permits  initializing  of  all  or  part  of  both  one  and  two  dimensional 
arrays. 


As  an  example,  consider  initializing  the  following  integer 
arrays  to  zero. 


DIMENSION  IRY(15,10),  JRY(15) 

a.  CALL  L0ADIU(0,15,10,3,IHY) 

b.  CALL  L0 AD IU(0 .1,15,1, JRY) 

c.  CALL  L0ADIU(0,1,15,1,IRY(1,M) 

d.  CALL  L0ADIU( 0 ,1,15*10 ,1 ,IRY ) 

e.  CALL  L0ADIU(0,1,5,1,JRY(11)) 

Example  (a)  above  rets  row  3  of  IRY  to  zero  according  to 
the  description  of  LOADIU  in  Section  V.  In  example  (b),  the  array 
JRY  is  set  to  zero.  The  parameters  imply  that  JRY  is  a  two  dimen¬ 
sional  array  with  1  row  and  15  columns.  The  CALL  to  LOADIU  initial¬ 
izes  row  1  l  the  only  row,  of  course).  This  example  demonstrates  how 
a  one  dimensional  array  can  be  initialized.  It  works  because  the 
elements  of  JRY  are  stored  contiguously  in  memory  by  FORTRAN. 

Example  (c)  is  an  extension  of  this  idea  to  initialize 
column  U  of  IRY.  Since  FORTRAN  stores  two  dimensional  arrays  by 
columns,  coliam  is  eontig’ious  in  memory  and  element  (l,U)  is  the 
location  of  its  beginning.  Example  (c)  treats  the  fourth  column  as 
a  one  by  15  two  dimensional  array  an£  initializes  the  first  row 
(which  is  in  fact  the  fourth  column  oi  IRY). 

Example  (d)  shows  how  to  use  this  idea  t.o  initialize  the 
entire  IRY  array  with  a  single  call  to  LOADIU.  F^r  this  case,  IRY 
is  treated  as  a  one  by  150  two  dimensional  array. 


Finally,  tie  lart  five  elements  of  JRY  can  be  initialized 
vith  the  statement  in  example  (e).  Here,  JRY(ll)  is  the  first 
element  to  he  initialized. 


2-0  COPYING  INFORMATION  TO  ARRAYS. 

The  Subroutine  COPYCU,  COPYIU,  and  COPYRU  will  copy  data 
free  one  character,  integer,  or  real  array  (respectively)  to 
another.  A  second  set  of  programs,  FUTCU,  FUTIU,  and  FUTRU,  permit 
arrays  to  be  copied  with  an  offset  to  other  arrays.  For  example. 


CALL  RJTIU(KRY,M6,20,LRY) 


will  copy  elements  one  through  four  of  KKY  to  elements  16  through 
19  of  LRY.  LRY  is  of  length  20. 


3-0  OPENING  AND  CLOSING  FILES. 

Subroutines  OFENDU  and  OPEISU  will  open  direct  access  and 
sequential  access  files,  respectively.  The  most  commonly  used  (or 
required)  parameters  of  the  FORTRAN  77  OPEN  statement  are  passed 
to  these  programs  as  formal  parameters  ( i.e. ,  unit  number,  file 
name,  status,  and  format).  The  files  are  opened  with  the  FORTRAN 
IOSTAT  parameter  and  the  resulting  error  code  ia  returned  through 
the  formal  parameter  I ERR.  Thus ,  if  a  system  I/O  error  occurs 
during  opening  of  the  file,  the  system  error  code  is  returned  from 
OPEHDU  or  OPENSU. 

Subroutine  INQUIRU  can  be  used  to  execute  a  FORTRAN  77  INQUIRE 
statement.  IHQUIPU  returns  parameters  indicating  if  a  file  ia 
opened,  its  file  name,  access  method,  and  format.  If  an  I/O  error 
occurs,  its  value  is  also  returned. 

b-0  TEXT  I/O. 

i 

UTIL  contains  several  utilities  for  printing  messages  to  an 
interactive  terminal  and  to  read  back  responses.  UTIL  makes  use 
of  programs  in  the  FFIN2  package  (Polito)  for  this  purpose. 

Subroutine  PHMU  is  a  general  purpose  program  for  printing 
messages  to  a  terminal.  The  calling  sequence  is  as  follows. 


SUBROUTINE  PRMU { LFD ,MSG , NPRNT ) 


HPHKT  is  the  unit  number  to  vrite  to.  MSG  is  a  CHARACTER  expres¬ 
sion  which  is  the  a. escape  to  he  written.  LFD  is  a  CHARACTER 
expression  of  up  to  35  characters.  LFD  is  a  portion  of  a  FORMAT 
statement  to  he  executed  before  MSG  is  printed,  For  example. 


CALL  PRMU( ' 5X ’ , ’MESSAGE • ,6) 


will  skip  five  spaces  before  printing  MESSAGE.  A  more  complex 
example  is 


CALL  PRMU( ’///2X,8HMY  HAME>’ , ’FOLITO* ,10) 


Subroutine  PAGEU  will  count  lines  on  a  page  and  execute  a 
page  eject  if  insufficient  space  remains  for  the  next  section  of 
output* 

Subroutine  NBLCU  will  delimit  the  non-blank  portion  of  a 
CHARACTER  variable.  NBLCU  will  examine  a  CHARACTER  variable  and 
return  the  character  position  of  its  first  end  last  non-blank 
character. 

Subroutine  PKMSU  prints  a  text  message  to  a  file  with  no  trail¬ 
ing  blanks.  Subroutine  NBLCU  can  be  used  to  find  the  last  non¬ 
blank  character. 

Character  function  RYNU  obtains  a  yes  or  no  response  from  the 
terminal  and  returns  a  single  character  that  is  one  of  'Y‘  or  'S'. 

The  user  may  respond  with  any  abbreviation  of  Yes  or  Ho  (e.g. ,  Y, 

YE,  or  YES).  RYrfU  must  be  declared  CHARACTER  *1  in  any  program 
which  uses  it. 

Subroutine  RETRYU  will  ask  the  user  if  he/she  wishes  to  re-try 
an  operation  which  has  failed.  Two  alternate  returns  are  provided: 
one  for  yes  and  one  for  no. 

5-0  SEARCHING  CHARACTER  ARRAYS. 

Function  IFCU  will  search  a  character  array  to  match  it  with  an 
input  character  expression.  In  other  words,  if  the  input  character 
expression  equals  the  fourth  element  in  the  character  array,  IFCU 
returns  the  value  four.  Only  the  non-blank  portion  of  the  input 
expression  i3  compared,  and  it  in  matched  with  the  leftmost  characters 
of  the  array  elements.  Thus,  the  input  text  may  abbreviate  the  array 
elements  tc  any  unique  string.  IFCU  returns  indications  of  success, 
failure,  or  ambiguous  input  strings.  IFCU  performs  a  linear  search 
in  the  character  array. 
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Function  ILFCU  has  the  same  characteristic  as  IFCU  except  it 
performs  a  binary  search  in  the  character  array.  The  user  need 
not  arrange  the  array  in  the  computer's  collating  sequence,  however. 
IBFCU  will  do  this  auxcmaticelly  hy  setting  values  in  an  index 
array  (also  provided  hy  the  user).  IBFCU  does  not  physically 
rearrange  the  character  array.  If  the  character  array  is  long  and 
if  many  searches  will  be  made,  IBFCU  will  be  much,  faster  than  IFCU. 


6-0  L0CAT1SG  PROGRAM  UNITS  IN  FORTRAN  77. 

Several  utilities  were  written  for  the  MOP/PS  project  to  aid 
in  management  of  the  FORTRAN  77  source  code.  Subroutine  FSRj  was 
used  by  these  utility  programs.  FSPU  is  not  called  from  any  of  the 
execution  or  user  interface  MOPADS  programs. 

FSPU  examines  a  character  string  to  determine  if  it  is  the 
first  or  last  statement  of  a  FORTRAN  77  program  unit.  FSPU 
recognizes  the  following:  PROGRAM,  SUBROUTINE,  FUNCTION  (all  types), 
BLOCK  DATA,  and  END  (FSPU  assumes  that  a  line  with  only  the  character 
"Bn}"  is  an  END  statement.  It  does  ret  examine  a  subsequent  line  to 
see  if  it  is  a  continuation  statement  which  might  cause  the  total 
statement  to  he  EfDIF) . 

FSPU  requires  "normal1*  separation  of  the  above  FORTRAN  etate- 
ments.  In  other  words  it  will  recognize 


CHARACTER *1  FUNCTION  RYNU 

but  not 

CHARACTER#1FUNCTI0NRYNU 


All  of  the  MOPADS  source  code  was  developed  with  the  PAA  LAMP 
utility  (Sutton,  Hixson),  so  FSPU  vill  also  recognize  "*DECK",  and 
"•COMDECK"  statements.  Distributed  versions  of  the  MOPADS  software 
do  not  contain  these  statements. 


7-0  MANAGING  AN  ARRAY  STACK. 

UTIL  contains  programs  that  generalize  the  familiar  notion 
of  maintaining  a  stack  of  values  erto  which  numbers  are  "FUSH"ed 
and  from  which  they  are  "P0P"ed.  The  stack  which  ia  maintained  hy 
UTIL  programs  is  a  stack  of  arrays. 
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Subroutine  SETVU  intializes  the  stack,  storage  array.  The 
user  passes  this  array  to  FETVU  as  a  parameter.  The  array  (named 
IARRAY  in  Section  V)  has  M  revs  and  H  columns.  N  must  be  the 
maximum  size  that  the  stack  will  <?ver  grow  to.  Integer  arrays  of 
length  M-l  may  be  stored  in  the  stack.  The  M-th  row  is  used  by  the 
utility  programs  to  manage  the  storage.  The  array  IARRAY  and  the 
variable  MFIRST  must  not  be  changed  by  the  user  between  calls  to 
these  programs. 

After  calling  SETVU  once.  Subroutine  INSCLU  is  called  to  "push” 
an  array  of  M-l  values  onto  the  stack.  IHSCLU  returns  the  column 
number  that  the  input  array  is  stored  in.  The  user  program  must 
"remember"  this  column  number,  because  the  "POP"  operation  ia  essen¬ 
tially  random  access.  In  other  vords,  any  column  of  IARRAY  may  be 
"POP"ed  without  regard  to  the  order  of  insertion. 

Subroutine  RMVCLU  does  the  "POP".  It  clears  the  specified 
column  and  makes  it  available  for  a  sew  array  to  be  stored  with 
INSCLU.  Mote  that  RMVCLU  does  not  return  the  information  stored  in 
the  "POP"ed  column.  The  user  must  access  this  information  directly 
from  the  specified  column  of  IARRAY. 


8-0  A  PSEUDO-COLLATING  SEQUENCE. 

MOPADS  has  need  to  code  single  characters  into  integers  and 
vice  versa.  The  UTIL  package  has  two  programs  that  do  this  in  a 
way  that  does  not  depend  upon  the  computer's  collating  sequence. 
Function  LPOSU  accepts  a  single  character  and  returns  an  integer 
code.  Only  the  capital  letters  and  numbers  may  be  coded.  The 
letters  A-Z  are  mapped  to  the  integers  1-26,  and  the  digits  0-9  are 
mapped  to  the  numbers  27-36,  respectively 

Character^  Function  CPOSU  performs  the  reverse  operation.  It 
accepts  an  integer  in  the  range  1-36  and  returns  a  single  character 
A-Z,  0-9,  respectively. 


9-0  DISTANCE,  HEADING,  SPEED. 

Subroutine  HEADNU  computes  the  distance  between  two  points. 
Given  two  points,  each  consisting  of  x,  y,  and  s  coordinates,  HEADNU 
computes  the  compass  azimuth  from  the  first  to  the  second  (radians 
from  north),  the  straight  line  distance  between  them  (miles),  and  the 
ground  distance  between  their  projections  on  the  s*0  plane  (miles). 

Subroutine  VECU  computes  the  components  of  a  velocity  vector. 
The  input  data  are  the  z  coordinates  of  two  points,  the  heading  from 
one  to  the  other,  the  straight  line  distance  from  the  first  point  to 
the  second,  and  the  magnitude  of  the  velocity  vector  from  the  first 
to  the  second.  The  outputs  are  the  components  of  the  velocity  vector 
in  the  x,  y,  and  z  directions. 


10-0  MISCELLANEOUS. 


In  addition  to  the  above,  UTIL  contains  programs  to  compare 
character  strings  (CEQVU),  compute  exponentially  smoothed  values 
(EXSMU),  sum  the  elements  of  an  array  (ISUMU,  RSUMU),  and  clip  an 
integer  expression  (NCLIPU).  The  use  of  these  programs  is  explained 
in  Section  V. 
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VII.  ERROR  PROCESSING 


The  UTIL  programs  have  no  centralized  error  processing.  Where 
appropriate,  each  program  in  UTIL  performs  its  own  error  processing. 
See  Section  V  and  VI. 
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VIII.  COMMON  VARIABLE  DEFINITIONS 


The  UTIL  programs  contain  a  single  COMMON  block  which  is 
initialized  in  BLOCK  DATA  BLOCKU.  BLOCKU  must  be  loaded  with 
any  programs  using  UITL.  The  COMMON  block  is  labeled  COM01U. 


Variable  Value 


Defintion 


This  character  array  contains 
the  characters  coded  by  LPOSU 
and  CPOSU  in  the  correct 
pseudo-collating  order. 


CHARS(36)*1 


The  letters  A-H 
and  the  digits 
0-9 
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XI.  CHANGE  NOTICES 


APPENDIX  R 
MOPADS  FINAL  REPORT: 

HUMAN  FACTORS  MODERATOR  FUNCTIONS 


i 


Standard  M0PAD3  Terminology 


AIR  DEFENSF  SYSTEM 

A  component  of  Air  IX  fense  which  includes 
equipment  end  operators  and  for  which 
technical  and  tactical  training  are  required. 
Examples  are  TEAWK  and  the  AN/TSQ-73. 

AIR  DEFENSE  SYSTEM 
MODULE 

Models  of  operator  actions  and  equipment 
characteristics  for  Air  Defense  Systems  in 
the  M0PAD8  software.  These  models  are  pre¬ 
pared  vith  the  SAINT  simulation  language. 

Air  Defense  System  Modules  include  the 

SAID!  model  and  all  data  needed  to  com¬ 
pletely  define  task  element  times,  task 
sequencing  requirements,  and  human  factors 
influences. 

AIR  SCENARIO 

A  spatial  and  temporal  record  of  aerial 
activities  and  characteristics  of  an  air 
defense  battle.  The  Air  Scenario  includes 
aircraft  tracks,  safe  corridors,  ECM,  and 
other  aircraft  and  airspace  data.  See 
also  Tactical  Scenario. 

BRANCHING 

A  ten  used  in  the  SAINT  simulation  lang¬ 
uage  to  mean  the  process  hy  which  TASK  nodes 
are  aequenced.  At  the  completion  of  the 
simulated  activity  at  a  TASK  node,  the 
Branching  from  that  node  determines  which 
TASK  nodes  will  "be  simulated  next. 

DATA  BASE  CONTROL 
SYSTEM 

That  part  of  the  MQPADS  software  which 
performs  all  direct  communication  with  the 
MOPADS  Data  Base.  All  information  transfer 
to  and  from  the  data  base  is  performed  by 
invoking  the  subprograms  which  make  up  the 
Data  Base  Control  System. 

DATA  SOURCE 

SPECIALIST 

A  specialist  in  obtaining  and  interpreting 
Amy  documentation  and  other  data  needed  to 
prepare  Air  Defense  System  Modules. 
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ENVIRONMENTAL 
STATE  VARIABLE 


An  element  of  an  Erreirenmentsl  State 
Vector. 


ENVIRONMENTAL 
STATE  VECTOR 


An  array  of  nines  representing  conditions 
or  characteristic*  that  may  affect  acre 
thri  one  operator.  Element*  of  iarirogaep- 
tal  Stats  Vectors  may  change  dynamically 
daring  a  MOPADS  aianlation  to  represent 
changes  in  the  environment  conditions. 


MODERATOR  FUNCTION 


A  mathematical /logical  relationship  which 
altera  the  nominal  time  to  perform  an  opera¬ 
tor  activity  (usually  a  Task  Element).  Tho 
nominal  time  is  changed  to  represent  the 
operator's  capability  to  perform  the 
activity  based  on  the  Operator's  Stats 
Vector. 


MOPADS  DATA  BASE 


A  computerized  data  base  designed  specifi¬ 
cally  to.  support  the  MOPADS  software.  The 
MOPADS  Data  Base  pnnt^nt  Simulation  Data 
Set(a).  It  eoiimn mi  rates  interactively  with 
MOPADS  Users  during  pre-  and  post-run  data 
specification  and  dynamically  with  the  SAINT 
software  during  simulation. 


MOPADS  MODELER 


An  analyst  who  will  develop  Air  Defense 
System  Modules  and  modify/ develop  the 
MOPADS  software  system. 


MOPADS  USER 


An  analyst  who  will  design  and  conduct  simu¬ 
lation  experiments  with  the  MOPADS  software. 


MSAINT 

(MOPADS/SAINT) 


The  variant  of  SAINT  used  in  the  MOPADS 
system*  The  standard  version  of  SAINT  has 
been  modified  for  MOPADS  to  permit  share¬ 
able  subnetworks  and  more  sophisticated 
interrupts.  The  terms  SAINT  and  MSAHIT  art 
used  interchangeably  when  no  confusion  will 
result.  See  also,  SAINT. 
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OPERATOR  STATE  One  element  of  an  Operator  State  Vector. 

VARIABLE 


OPERATOR  STATE  An  array  of  values  representing  the  eondi- 

VECTOR  tion  and  characteristics  of  an  operator  of 

an  Air  Defense  System.  Many  values  of  the 
Operator  State  Vector  vill  change  dynamically 
during  the  course  of  a  MOPADS  simulation  to 
represent  changes  in  operator  condition. 


OPERATOR  TASK  An  operator  activity  identified  during 

veapons  system  front-end  anelyses. 


SAINT  The  underlying  computer  simulation  language 

used  to  model  Air  Defense  Systems  in  Air 
Defense  System  Modules.  SAXHT  Is  an  acronym 
for  Systems  Analysis  of  Integrated  Networks 
of  Tasks.  It  is  a  veil  documented  language 
designed  specifically  to  represent  human 
factors  aspects  of  man /machine  systems. 

Bee  also  MSAIHT. 


SIMULATION  DATA  SET  The  Tactical  Scenario  plus  all  required 

simulation  initialization  ana  other  experi¬ 
mental  data  needed  to  perform  a  MOPADS 
simulation. 


SIMULATION  STATE  At  any  instant  in  time  of  a  MOPADS  simula¬ 

tion  the  Simulation  State  is  the  set  of 
values  of  all  variables  in  the  MOFADS  soft¬ 
ware  and  the  MOPADS  Data  Base. 


SYSTEM  MODULES  See  Air  Defense  System  Modules. 

TACTICAL  SCENARIO  The  Air  Scenario  plus  specification  of 

eriticsl  assets  and  the  air  defense  ccm-' 
figuration  (number,  type  and  location  of 
veapons  and  the  cemraand  and  control  system) . 
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TACTICAL  SCENARIO  * 
COMPONENT 

An  element  of  a  Tav-ierl  Scenario,  e^g. , 

If  a  Tactical  Scenario  contains  several 

Q-73'a,  each  one  is  a  Tactical  Scenario 

Component. 

TASK 

See  Operator  Task. 

TASK  ELEMENTS 

Individual  operator  actions  vhich,  vhea 
grouped  appropriately,  sake  up  operator 
tasks.  Task  elements  are  usually  repre¬ 
sented  by  single  SAINT  TASK  nodes  in  Air 

Defense  System  Modules. 

TASK  NODE 

A  modeling  symbol  used  in  the  SAINT  simula¬ 
tion  language.  A  TASK  node  represents  en 
activity;  depending  upon  the  modeling  cir¬ 
cumstances,  a  TASK  node  may  represent  an 
individual  activity  such  as  a  Task  Element, 
or  it  may  represent  an  aggregated  activity 
such  as  an  entire  Operator  Tu^k. 

TASK  SEQUENCING 
MODERATOR 

FUNCTION 

A  mathematical/logical  relationship  vhich 
selects  the  next  Operator  Task  vhich  an 
operator  vill  perform.  The  selection  is 
based  upon  operator  goal  seeking  character¬ 
istics. 

ADDITIONAL  MOPADS  TERMINOLOGY 

SKILLS 

Components  of  human  task  performance 
vhich  are  required  for  successful 
completion  of  the  task. 

SKILL  MODERATOR 
FUNCTION 

FORTRAN  subroutines  vhich  dynamically 
alter  simulated  skill  performance  during 
the  course  of  a  simulation  run. 

TASK  VECTOR  or 

TASK  SPECIFIC 
CHARACTERISTIC 

A  list  of  data  that  is  associated  with  a 
task  element  rather  than  with  the  operator 
who  performs  the  tasks,  e.g.,  the  energy 
expenditure  required  tc  perform  the 
task  elements. 
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I.  PURPOSE 


Tha  purpoaa  of  tha  software  described  herein  ia  to 
aaka  tha  h’lBjan  operator  models  'behave'  more  like 
humans  whan  ^eriablas  known  to  affect  human  performance 
are  considered.  In  previous  SAINT  modeling  efforts, 
parameters  associated  with  human  performance,  such  as 
time  to  perform  und  probability  of  succesaful 
performance,  were  treated  simply  as  random  variables 
with  a  known  distribution  and  distribution  parameters 
(e.g>,  normal  distribution  with  a  mean  of  2.0  and  a 
standard  deviation  of  0.60).  We  know,  however,  that 
variability  around  the  mean  of  human  performance  is  not 
simply  random.  This  variability  is,  by  and  large, 
caused  by  a  variety  of  factors  which  affect  the  human's 
ability  to  perform  his  tasks.  Obvious  examples  of 
these  factors  are  environmental  stressors  (e.g.,  heat, 
noise),  operator  variables  (e.g.,  intelligence, 
training),  and  task  variables  (e.g.,  workload,  task 
difficulty)  .; 

The  problems  faced  when  developing  causal 
relationships  between  these  factors  affecting 
performance  and  corresponding  human  performance  are 
many  and  varied.  To  be  of  use  to  e  simulation  modeler, 
these  relationships  must  be  represented  mathematically. 
With  some  notable  exceptions,  the  human  factors 
literature  ia  relatively  weak  in  documenting  causal 
relationships.  In  cases  where  causal  claims  are  made, 
they  are  not  usually  represented  mathematically.  A 
classic  example  of  this  is  a  report  describing  a  study 
where  regression  analysis  is  used  to  positively  link 
human  performance  to  some  variable,  yet  all  that  is 
reported  is  the  significance  level  of  the  test  and  not 
the  derived  regression  equation. 

Therefore,  our  first  task  was  to  reformulate  as 
much  of  the  relevant  human  factors  literature  as 
possible  into  these  mathematical  relationships.  This 
process  is  outlined  in  HOPADS  reports  5.1,  5.2,  5.5, 
and  5.6  in  considerable  detail.  To  briefly  summarize 
this  process,  the  human  factors  literature  was  reviewed 
and  each  piece  of  literature  was  categorized  with 
respect  to  the  type  of  skill  which  was  studied.  The 
skill  taxonomy  which  was  used  is  presented  in  Table 
I-l.  Furthermore,  the  articles  were  categorized  with 
respect  to  how  skill  performance  was  measured  (i.e.. 
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SKILL  CATEGORIES 
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PROBABILITY-ESTIMATION 

TIME-ESTIMATION 

LTN-SENSORY 

LTM-SYMB0L1C 

STM-SENSORY 

STM-SYMBOLIC 

NUMERIC-MANIPULATION 

RECOGNITION 

UNUSED 

UNUSED 

TIHE-SHARINB 

DETECTION 

FINE-MANIPULATION 

DROSS-MANIPULATION 

U^'ID 

RAL-PHYSICAL -EFFORT 
V.  IION-T1ME 
TR  .UNO 

TEAM-COORDINATION 
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tin*  to  couplet*  or  probability  of  teak  completion  usa 
Measured).  Then,  those  articles  which  provided 
sufficiently  detailed  information  were  used  to  build 
mathematical  relationships  between  the  skill  studied 
and  the  independent  variable(s)  studied.  Curve  fitting 
techniques  were  employed  and  many  relationships 
quantitatively  defined. 


At  this  point  in  the  project,  we  had  a  number  of 
mathematical  relationships  describing  how  'generic' 
skill  performance  was  affected  by  a  set  of  independent 
variables.  To  be  useful  to  the  simulation  modeler,  this 
information  had  to  be  translated  into  a  form  which 
could  be  readily  Incorporated  into  a  task  network 
simulation. 


The  approach  selected  involved  the  development  of  a 
set  of  skill  moderator  functions  from  the  literature. 
These  skill  moderator  functions  take,  as  input,  the 
mean  time  or  probability  of  performing  the  task  (which 
requires  use  cf  that  skill >  and  the  current  values  of 
th*»  independent  variables  which  will  affect  performance 
of  this  skill.  Then,  the  moderator  functions  reestimate 
the  mean  time  or  probability  baaed  upon  the  values  of 
the  independent  variables  and  provide  this  as  output. 
The  result  is  an  estimate  of  mean  performance  based 
upon  the  state  of  t.he  system  as  represented  by  the 
independent  variables. 


The  task  to  the  modeler  is  reduced  tol  relatively 
few  activities.  First,  he  must  identify  the  skills 
Involved  in  esch  task.  It  is  anticipated  that  some 
tasks  will  involve  more  than  one  skill.  In  this 
case,  the  modeler  must  decide  the  relatival  importance 
of  each  skill  by  assigning  a  percentage  to  each  of  the 
component  skills  of  the  task  (they  must  add  up  to  100). 


Second,  the  modeler  must  develop  a  data  structure 
scheme  to  maintain  tha  independent  variables.  In  the 
MOPADS  context,  the  Information  is  maintained  in  the 
HOPADS  data  base.  If  these  moderator  functions  arcs 


/ 


used  in  another  setting,  thr  data  may  ba  maintained  in 
any  form  so  long  aa  they  are  aecaaaible  to  the  seders cor 
function  module  in  a  atandard  format.  To  accomp^iui'. 
thia,  the  analyst  muat  build  the  following  three 
subroutines  to  tranafar  the  valuaa  of  the  independent 
variables  to  the  moderator  function  subroutines: 

1.  GETEVA 

2.  GETGVA 

3.  GETTSA 

4.  TIMEA 

More  detail  on  the  parametara  which  era  paaaad  to  and 
from  these  aubroutinaa  will  ba  covered  in  Section  IV  of 
thia  report. 


Finally ,  the  modeler  muat  write  a  amall  amount  of 
aoftware  to  identify  the  ckilla  involved  in  the  t s>v 
currently  being  executed  by  the  model,  call  the 
moderator  function  aubroutinea  for  these  skills,  and 
then  combine  the  new  estimates  of  the  mean  (if  multiple 
skills  a re  required  by  the  task)  into  a  single  weighted 
estimate. 


The  rwmalnder  of  this  report  will  focus  on  the 
skill  moderator  functions.  Only  Section  IV  will 
address  any  details  of  external  requirements  of  the 
subroutines.  It  should  however,  be  strongly  emphasized 
that  these  moderator  functions  are  not  MOPADS  specific. 

If  the  interfaces  discussed  above  are  developed,  these 
moderator  functions  can  be  used  in  any  task  network 
simulation.  Their  utility  is  only  limited  by  the  extent  to 
which  the  skill  categories  are  appropriate  for  the  tasks 
being  modeled.  We  anticipate  that  most  tasks  which  are 
low-level  cognitive,  procedural,  and/or  physical  in  nature 
can  bo  appropriately  modeled  with  these  subroutines.  On 
the  other  hand,  taaks  which  are  predominantly  cognitive 
(e.g.,  problem  aolving)  or  require  predominantly  highly 
skilled  psychomotor  behavior  may  be  better  modeled  with 
other  techniques. 
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It  in  also  worthy  to  note  that  these  Moderator 
functions  should  not  be  viewed  as  'sacred  cows  not  to 
be  fooled  with.'  In  fact,  we  hope  that  the  Moderator 
functions  can  continue  to  develop  and  grow  with  the 
state-of-the-art  in  aatheaatical  Modeling  cf  hunan 
performance.  Special  care  has  been  given  to  docueent 
every  segment  of  code  which  affects  mode'.ed  human 
perfornance  so  that  the  source  of  that  mat henatical 
relationship  can  be  determined.  During  the  course  of 
developing  these  subroutines.  Many  decisions  had  to  be 
made  as  to  which  model  was  best  and,  therefore,  should 
be  included.  Others  aay  justifiably  dispute  these 
judgments.  We  encourage  anyone  wishing  to  change  these 
subroutines  to  rsflect  their  judgment  and/or  to 
reflect  new  findings  in  human  performance  to  do  so.  We 
ssk  only  that,  if  possible,  these  changes  be  forwarded 
to  the  authors  no  thnt  we  may  continue  to  improve  the 
fidelity  of  the  skIII  moderator  subroutines. 
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IS.  DATA  STRUCTURE  DESCRIPTION 


Sine*  tit*  moderator  function*  *r*  •  **t  of  more  or 
1**«  unrelated  subprogram*,  they  have  no  major  internal 
data  structure.  The  exception  to  this  is  the  set  of 
Independent  variable*  which  ere  considered  in 
daterainlng  moderated  performance.  However,  the 
specific  nature  of  where  and  how  these  variables  are 
stored  ie  not  of  concern  to  the  moderator  function*. 
Rather,  it  must  be  considered  by  those  writing  the 
Interface  subroutines  GETEVA,  GETOVA,  and  CETT3A  to  be 
discussed  in  Section  IV. 

In  summary,  these  subroutines  contain  no  COHMOM 
blocks  and  all  required  data  are  passed  as  formal 
parameters. 


ZIZ.  OVERVIEW  OF  FLOW  OF  CONTROL 


Tha  aodarator  subprogram*  ar*  cal lad  by  uaar 
prograaa  (in  thia  caaa  NOPADS).  Each  moderator 
function  haa  tha  aaaa  calling  sequence  aa  daacribad  in 
Saction  VI.  Thia  standardization  ensures  that 
information  is  paaaad  to  and  from  tha  aodarator 
functions  in  a  uniform  way. 


Tha  aodarator  functions  raturn  raviaad  estimates 
of  tha  task  tima  or  probability  to  coaplato.  To  do 
this*  thay  aay  require  accaa*  to  tha  oparator  atata 
vactora,  tha  anvironaantal  atata  vactora,  and/or 
various  data  that  ar*  particular  to  tha  task  (called 
taak  vactora  hare).  Four  standard  subprograms  ara 
called  by  tha  moderator  functions  to  obtain  thia 
information.  Thay  are: 

GETOVA  -  Gat  oparator  stat*  vector  information 
GETEVA  -  Gat  environmental  state  vector 
information 

GETTSA  -  Gat  task  vector  information 
TINEA  -  Gat  tha  currant  military  time 

In  HOPADS,  thaaa  programs  ara  provided  aa  database 
application  prograaa  and  are  described  in  MOPADS  Voluma 
3.18.  In  other  applications,  these  programs  would  have 
to  be  written  to  accaa;  the  data  structures  created  by 
the  modular  procedures  for  writing  thaaa  Interfaces  as 
contained  in  Section  VI. 


Outputs  fro*  tha  moderator  functions  include  a 
moderated  mean,  a  moderated  standard  deviation,  and  a 
new  distribution  type.  At  this  writing  the  moderator 
functions  only  affect  the  mean.  Thia  is  becauee  of  a 
lack  of  data  to  make  estimates  of  variability  or 
distribution  changes.  The  module,  however,  has  been 
designed  to  accommodate  such  estimates  in  the  future 
without  changes  to  the  information  interface. 


V.  SUBPROGRAM"  DESCRIPTIONS 


The  following  p*tgaa  includa  printouts  for  aach  of 
tha  32  aodarator  subroutines.  Thaaa  aubroutlnaa  art 
liatad  alphabatlcally  in  tha  following  ordar: 


I.  Detaction  probability 
2*  Dataction  tiaa 

3.  Fina  aanipulativa  ability  probability 

4.  Fina  aanipulativa  ability  tiaa 

5.  Ganaral  phyaical  affort  probability 

6.  Ganaral  phyaical  affort  tins 

7.  Groaa  aanipulativa  ability  probability 
6.  Groaa  aanipulativa  ability  tiaa 

9.  Long  tarn  aaaory-aanacry  probability 

10.  Long  tara  aaaory-aanaory  tiaa 

II.  Long  tara  aaaory-ayabolic  probability 

12.  Long  tara  aaaory-ayabolic  tiaa 

13.  Nuaaric  Manipulation  probability 

14.  Nuaaric  aanipulatlon  tiaa 

15.  Probability  aatiaation  probability 

16.  Probability  aatiaation  tiaa 

17.  Raaction  tiaa  probability 

18.  Raaction  tiaa 

19.  Recognition  probability 

20.  Racognltion  tiaa 

21.  Short  tara  aaaory-aanaory  probability 

22.  Short  tara  aaaory-aanaory  tiaa 

23.  Short  tara  aaaory-ayabolic  probability 

24.  Short  tara  aaaory-ayabolic  tiaa 

25.  Taaa  coordination  probability 

26.  Taaa  coordination  tiaa 

27.  Tiaa  aatiaation  probability 

28.  Tiaa  aatiaation  tiaa 

29.  Tiaa  aharing  probability 

30.  Tiaaaharlng  tiaa 

31.  Tracking  probability 

32.  Tracking  tiaa 


Via  ahould  nota  that  a  nuaber  of  thaaa  aoderator 
aubroutlnaa  do  not  contain  any  axacutabla  coda.  This 


it  dut  to  either  a  lack  of  data  in  tha  human  factors 
literature  regarding  that  akill  or  our  inability  to 
locate  thaaa  data  within  tha  available  contract 
resources.  Again,  we  encourage  any  individuals  with 
information  on  these  skills  to  forward  this 
information  to  tha  authors. 


Tha  comment  sections  at  the  beginning  of  each 
subprogram  describe  all  parameter  and  local  variable 
definitions.  Note  that  the  HQPADS  aanigned  suffix  for 
this  module  is  “H“ .  All  subprograms  end  with  an  **HM. 
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SUBROUTINE  DtTEPHUDO.  IDE.  N.  DXST. 

I 


XT ASK. 


XH) 


C • IMODULC t  HUMAN  FACTORS  MODERATOR  FUNCTIONS 
C* •REFERENCE* NOPADS/ VOLUME  9.10  OP 
C 

Cl  •PURPOSE*  THIS  SUBROUTINE  RETURNS  PAOBABILI TY-TO-DCTECT  MODERATORS 
C  FOR  AUDITORY  AND/OR  VISUAL  TASKS 

C 

CM  INPUT  PARAMETERS* 


C 
C 

c 
c 
c 
c 
c 
c 
c 
c 

CMOUTPUT  PARAMETERS* 

C  Until  -  SKILL  CATEGORY  MODERATOR  VALUES 


IDO  <N>  -  ADDRESS I NO  INFORMATION  FOR  THE  OPERATOR 
IDE  <NJ  -  ADDRESS  INQ  INFORMATION  FOR  THE  ENVIRONMENT 
It ASK  -  ADDRESSING  INFORMATION  FOR  THE  TASK 
N  -  INDEX  FOR  IDO  AND  IDE 
NTS  -  INDEX  FOR  XTA8K 
DXST  <3>  -  NOMINAL  TASK  PARAMETERS 
(!)  MEAN 

(2)  STANDARD  DEVIATION 
<3>  DISTRIBUTION  TYPE 


XM(l)  •  DIFFERENCE  BETWEEN  DERIVED  AflD  BASELINE 
MEAN 

XM<2>  •  DIFFERENCE  BETWEEN  DERIVED  AND  BASELINE 
STANDARD  DEVIATION 
XM<3>  •  DERIVED  DISTRI BUTXON  TYPE 


I  ABLE 9  USED  IN 


C 
C 

c 
c 
c 
c 

Cl  I 

CMLOCAL  VARIABLES* 

C  KO  -  NUMBER  OP  OPERATOR  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTION  I 

C  KI  -  NUMBER  OF  ENVIRONMENTAL  INDEPENDENT  VfcRI fi 

THIS  moderator  function 

NT  -  NUMBER  OP  TASK  INDEPENDENT  VARIABLES  USED  IN 
THIS  MODERATOR  FUNCTION 

NED  CKO)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  OPERATOR 
STATE  VECTOR 

NEECKE)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  ENVIRONMENT 
STATE  VECTOR 

NTASKtNT)  -  ELEMENT  NUMBERS  OP  VARIABLES  IN  THE  TASK  VECTOR 
NNE  -  NUMBER  OP  MODERATOR  EQUATIONS 

N1V(!»  -  NUMBER  OF  INDEPENDENT  VARIABLES  IN  MODERATOR 
EQUATION  I 

Ptl>  -  PROBABILITY  TO  COMPLETE  CALCULATED  FROM  MODERATOR 
EQUATION  I 


C 

c 

C 
C 

c 
c 
c 
c 
c 
c 
c 
c 
c 
c 

C • ID  I MENS ION  ARRAYS 
C 

DIMENSION  1D0CN).  IDECN).  DI3TC3). 
DIMENSION  **€0115).  NEEC2).  NT5k(2> 
DIMENSION  XE <2) . XQC1S) . XTSK (2> 

C 

CftDCFIHE  LENGTH  OP  ENVIRONMENTAL.  OPERATOR. 


I TASK (NTS) 
HlVtfc).  P(A). 
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C  AND  TASK  STATE  VECTORS 
C 

DATA  KE/2/ 

DATA  KO/ 19/ 

DATA  NT/2/ 

C 

C( (DEFINE  NEEDED  ELEMENT  NUMBERS 
C 

DATA  NEE/6.1/ 

DATA  NEO/32.29.3. 44.12.40.27. 36.19. 34. 4. 16, 49. 49, 47/ 

DATA  NT8K/3. 6/ 

C 

Ct (DEFINE  THE  VECTOR  ELEMENTS 
C  XE  < 1 > “NUMBER  OF  OPERATORS  ON  DUTY 

C  XE (2)— AMBIENT  DRY  BULB  TEMPERATURE  IN  DEGREES  CENTIGRADE 
C  X0(1)-TH€  NUMBER  OF  CONSECUTIVE  NlGHT 3  FOR  WHICH  THE 
C  DURATION  OF  THE  OPERATOR'S  SLEEP  PER 

C  NIGHT  IB  KNOWN 

C  XO <2>— THE  OPERATOR'S  AVERAGE  AMOUNT  OF  SLEEP  PER  NIGHT  IN  HOURS 
C  X0<3>-T1ME  ON  TASK  IN  HOURS 

C  X0<4)-THE  OBSERVER'S  FIEL0-OF-VIEW  IN  DEGREES 
C  XO (9) -TARGET  TYPE 

C  X0(6> -HORIZONTAL  RANGE  TO  TARGET  IN  NAUTICAL  MILES 
C  XO <7 > -TARGET /BACKGROUND  CONTRAST  RATIO 
C  XO<S)-THE  APPARENT  CONTRAST /THRESHOLD  CONTRAST  RATXC 
C  X0< 4) -OBSERVER'S  SEARCH  AREA  IN  DEGREES 
C  X0(10> -AIRCRAFT  ALTITUDE  ABOVE  GROUND  IN  FEET 
C  X0< 11) -OPERATOR'S  DAYS  ON  DUTY 
C  XO < 12) —USE  OF  BINOCULARS 
C  XO (13) -OBSERVER  OFFSET  IN  NAUTICAL  MILES 
C  X0<14)-L1N£  RESOLUTION  ON  A  CRT 
C  X0< 13) -TARGET  LOCATION  ON  SCREEN 
C  XTBK ( 1 ) — TASK  MODALITY 

C  XTSK <2>  — THE  OBSERVER- TO- TARGET  POSITION 
C 

Ct (RETRIEVE  VALUES  FOR  OPERATOR.  ENVIRONMENTAL  AND  TASK  STATE  VECTORS 
C 

CALL  QCTOVA  (IDO.  N.  NCO.  KO.  XO) 

CALL  GETEVA  (IDE.  N,  NEE.  KE.  XE) 

C 

CitNTSK  CONTAINS  ELEMENT  NUMBERS  OF  THE  TASK  SPECIFIC  HUMAN  FACTORS  DATA 
C 

ZOPT-I 

CALL  GETTSA  U0PT.XTA8K.  NTS.  HTSK.  NT.  XTBK) 

C 

CMINIT1AL1ZE  NME.  NIV 
C 

NME-O 
NIV <11-0 

c 

C* (EVALUATE  XM 

C((XT8K ( 1 ) —TASK  MODALITY 

C 

IF  (XTSK(l).EQ.  1.0)00  TO  1 
IF  (XTSK  < 1 ) . EO. 10. 0) GO  TO  2 
IF  (X18K(1) .EQ. 11.0)80  TO  30 
C 

CMIHE  TARGET  IB  AUDITORY 

C((*0<1>— THE  NUMBER  OF  CONSECUTIVE  NIGHTS  FOR  WHICH  THE  DURATION  OF  THE  OPERA- 
C  TOR'S  SLEEP  PER  NIGHT  IS  KNOWN 

C((X0<2)-THE  OPERATOR'S  AVERAGE  AMOUNT  OF  SLEEP  PER  NIGHT  IN  HOURS 

CMDATA  FROM  SIEGEL.  PFEIFFER.  KOPSTEIN.  WILSON.  AND  OZKAPTAN.  1479.  PAGE  127 

C 

1  NHC-NMOl 
NIV (NME) —2 

IF  'X0<» * .10, 1.0)  THEN 


R-20 


H {NHL) -v. 6 30-0. U/4*EXP l-V. 1  J3*XU<2/  M2) 

KLSS 

P  (NhC)  "■0.434+0.  036*  X0<2> -0.004*  <X0<2>  M2> 
END  IF 


CMX0<3>-TIM6  ON  TASK  IN  HOURS 
CMXMIN^TIME  ON  TASK  IN  MINUTES 

CMDATA  FROM  SIEGEL.  PFEIFFER.  KOPSTEIN.  WILSON.  AND  OZKAPTAN.  1474.  PAGE  134 
C 

NME-NME+J 
NIV(NME>-1 
XMIN-X0<3>  *60.0 

P  <NME)  »0.  437-0. 003*XHIN+0. 00003$  <XMINM2) 


C* (CALL  ABSPMH  TQ  DERIVE  SKILL  MODERATORS  FOR  AUDITORY  DETECTION 
C 

CALL  ABSPMH < DIST. NI V. NME.P. XH) 

00  TO  444 
C 

CM  THE  TARGET  IS  VISUAL 

CMXTSM2>-THE  OBSERVER-TC. -TARGET  POSITION 

CMNPQS»THE  OBSERVER- TO- TARGET  POSITION  AS  AN  INTEGER  VARIAFLE 
C 

2  NP09-NINT<XTSK<2)> 

GO  TO  ( 3. 4. 3. 28. 24) NPOS 
C 

CM1  HIS  IS  A  GROUND-TO-GROUND. VISUAL  DETECTION  TASK 
CMXMIN»TIME  DN  TASK  IN  MINUTES 

CMDATA  FROM  SIEGEL.  PFEIFFER.  K0PSTE1N.  WILSON.  AND  OZKAPTAN,  1474.  PAGE  134 
C 

3  NME-NME+1 
NIV<NME>-1 
XM1N-X0<3> *60.0 

P  tNME>  »0.  S76-0. 0O9*XMIN*0.  OOOl  *  ( XMINM2) 

C 

CMCALL  ABSPMH  TO  DERIVE  SKILL  MODERATORS  FOR  GROUND-TO-GROUND. VISUAL  DETECT I ONN 
C 

CALL  ABSPMH ( DIST • NI V. NMc . P . XM) 

GO  TO  444 
C 

CMTHIS  IS  AN  AIR  -TO-GROUND.  VISUAL  DETECTION  TASK 
CMX0<4>-THE  OB*  -RVER'S  FJELD-OF-VIEW  IN  DEGREES 
CMDATA  FROM  SCANLAN.  1976,  PAGE  67 
C 

«  MHE-NME-M 
NIV<NME)-1 

P<NME)-O.336+O.O22*XO<4)-O.OO2*<X0(4>M2> 

C 

CMC  ALL  ABSPMH  TO  DERIVE  SKILL  MODERATORS  FOR  AIR-TO-GROUND  VISUAL  DETECTION 
C  TASK 
C 

CALL  ABSPMH (DIST. NIV. NMC. P. XN> 

GO  TO  449 
C 

CM1HIS  IS  A  GROUND-TO-AIR.  VISUAL  DETECTION  TASK 
CMX0(3>-TAR0£T  TYPE 

CMMIAPG-IARGET  TYPE  AS  AN  INTEGER  VARIABLE 
CM  XO<ft>  “HORIZONTAL  RANGE  TO  TARGET  iN  MAUT  l  CAL  MILES 
CtfXKM-HORIZONl AL  RANGE  TO  TARGET  IN  KILOMETERS 
LMD'UH  FROM  WRIGHT.  1966,  PAGES  16.  17.  AND  13. 

C 

3  NTARG«NINT(X0(3) ) 

XKM*X0<6>  *1.852 

IF  ( XO (3) . GT. 10. 0) GO  TO  17 

NME-NME+1 

Ni‘MMME>-2 


00  TO  <*.7.*.9  10.11.12. 13. 14,13>NTAR3 


C 

CtJTAftOCY  IS  AH  F-4C 
C 

*  P<NMt>— 0.401*1. 447*  <-0.002«XKHM2> 
00  TO  17 


c 

CMTARGCT  It  AN  F-iOO 
C 

7  P<NMe>-0. 071*0.  4S4(EXP<-0.004*XKMt*2> 
00  TO  17 


C 

CMTAROST  It  A  T-33 

c 

8  P(NMt>-0. 034*0. 9e0*EXP(-0.013*XKht*2> 
00  TO  17 


C 

CM  TARGET  IS  ANOTHER  TYPE  OF  JET 
C 

8.  R<NME> -0. 037*0. 99**EXP<-O.OOe«XKMM2> 
00  TO  17 


C 

Off  TARGET  IS  A  U-1A 
C 

10  P<NME>— 0.330*  1.421  *EXP  (-0.003*  XKMM2) 
00  TO  17 


C 

Cf (TARGET  18  A  U-*A 
C 

11  P(NME) — O. 000*1 » 143*EXP (— 0. 01A*XKM**2) 

CO  TO  17 

C 

CMIAAGET  It  ANOTHER  TYPE  OF  PROPELLER  AIRCRAFT 
C 

12  P<NME>— 0.011*1. 071  (EXP (-0.009*XKMM2> 

GO  TO  17 


C 

CM  TARGET  IS  AN  O-IA 
C 

13  P <NME> -0.010*1. 121  (EXP  (-0. 022*XKHM2> 
00  TO  17 


C 

CtriARGET  IS  AN  0H-23 
C 

14  P  (NME>-0. 010*0. 941  «EXP(-0.019*XKMM2> 

00  TO  17 
C 

C«* TARGET  It  ANOTHER  TYPE  OF  HELICOPTER 
C 

13  P (NME> -0. 014*0. 937*EXR (-0. Q30*XKM**2> 

C 

CMXO( 7) -TARGET /BACKGROUND  CONTRAST  RATIO 

CM  XO(B)  -THRESHOLD  TARGET/ BACKGROUND  CONTRAST  RATIO 

CMCCT— THE  APPARENT  CONTRAST /THRESHOLD  CONTRAST  RATIO 

CMDATA  FROM  SUGARHAN.  HAMM  ILL.  AND  DEUTSCHMAN.'  1972.  PAGE  B-2 

C 

17  MHE-NHE*! 

NIV(NME)— 2 
CCT-XO ( 7) /XO<0> 

R(NME) — 1 • 01 i-1 • 1736*EXR<-1 ,374*CCTM2> 

C 

CMXO  (9  > -OBSERVER'S  SEARCH  AREA  IN  DEGREES 
CMXO  <  10) -AIRCRA'  T  ALTITUDE  ABOVE  BROUND  IN  FEET 
CMXkVHRD— HORIZONTAL  DISTANCE  TO  TARGET  IN  THOUSANDS  OF  YARDS 
CMDATA  FROM  WOKOUN.  I960.  PAGES  23  TO  33 
C 


R-22 


Nhfc-NMfc+1 

NIV(NME)-? 

XKYARD*  XO (6) »*•  023 

IF  <XQ( 10) .LT. 1 TOO. 0)30  TO  22 

IF  (X0(9) .GT. 100.0)50  TO  18 

IF  (X0<9> .  LE. 180.0. AND. XQ(9> .QT. 90.0) GO  TO  If 
IF  ( XO (9) . LE. 90.0. AND. XO <9)  • GT . 43*0)00  TO  20 
IF  <X0<9> .LE.45.0>00  TO  21 
C 

CMTARGET  ALTITUDE  IS  AT  LEA9T  1500  FEET 
CMQBRERVER  SKA3CK  AREA  GREATER  THAN  l  BO  DEGRESS 
C 

18  P  <NME>-0. 049*0.  783(£XP<-0. 143(XKYARDM2> 

00  TO  27 

C 

CM  TARGET  ALTITUDE  13  AT  LEAST  500  FEET 
C ((OBSERVER  SEARCH  AREA  91  TO  1B0  DEGREES 
C 

19  P <NME>-0. 058*0.  .^(EXPl-O.  165(XKYARDM2> 

00  TO  27 

C  ' 

CM  TARGET  ALTITUDE  IB  AT  LEAST  1500  FEET 
C( (OBSERVER  SEARCH  AREA  46  TO  90  DEGREES 
C 

20  P (NHE) -0. 033*0. 668(EXP < -0. 037t  XKYARDM2) 

GO  TO  27 

C 

CM  TARGET  ALTITUDE  19  AT  LEAST  1500  FEET 
C( (OBSERVER  SEARCH  AREA  LESS  THAN  46  DEGREES 
C 

21  P<NME>— O.  115*0. 96l(EXP<-0.O56(XKYARDM2> 

00  TO  27 

22  IF  <X0  <9> . GT. 100.0)00  TO  23 

IF  (X0<9) .LE. 100.0. AND. X0<9) .GT. 90.0)00  TO  24 
IF  ( XO <9) , LE. 90.0. AND. XO (9) • GT .45.0) GO  TO  23 
IF  (X0<9) .LE. 45. 0) GO  TO  26 
C 

CM )ARGET  ALTITUDE  IS  LFSS  THAN  1500  FEET 

C( (OBSERVER  SEARCH  AREA  GREATER  THAN  130  DEGREES 

C 

23  P <NHE>-0. 019*0.  733(EXP<-0.0B2(XKYARDM2> 

00  TO  27 

C 

CM  TARGET  ALTITUDE  IS  LESS  THAN  1500  FEET 
C( (OBSERVER  SEARCH  AREA  91  TO  180  DEGREES 

w 

24  P<NME> -0.030*0.  709(EXP<-0.  103(XKYAR0M2> 

GO  TO  27 


C( (TARGET  ALTITUDE  IS  LL9S  THAN  1500  FEET 
C( (OBSERVER  SEARCH  AREA  46  TO  90  DEGREES 
C 

25  P (NHE) -0. 039*0. 607(EXP < -0. 039CtKVARD( (2> 

GO  TO  27 

C 

CMTARGET  ALTITUDE  13  LESS  THAN  1500  FEE.* 

C( (OBSERVER  SEARCH  AFEA  LESS  THAN  46  DEGREES 
C 

26  P<Nh€) -0.046*0.  790(EXP<-0.055(XKYARDM2> 

C 

CMXOU  1  >-0PERAT0R'9  DAYS  ON  DUTY 

CMDATA  FROM  SUGARtlAN.  HAHNILL.  AND  DEUTCHHAN.  1972.  .PAGE  C 
C 

27  NHE-NHE+1 
NI V (NHE) — 1 

P (HUE  >  — O. 739*0. 807(EXP  <  — 1 .0(XQ<*1>((2> 


R-23 


Ct?X0(12)»USE  OF  BINOCULARS 
C440ATA  FROM  NRISNT,  1444. 

C 

MIV(MHK>«2 

IF  (XO(12)  10. 0.O)  THEN 

F (NHK  >  •©. 04*1 . 032IEXP  (-0. 0044XKM442) 


14 


P(NHE)«O.<X»+O.4474CXP<-0.0iltXKn4t2) 
KMP1F 
C 

C4iXOU3>-OSSCRVtR  OFF  BIT  IN  NAUTICAL  KILO 

C44xheter«oss£rvea  offset  in  hctcrs 

C44DATA  FROM  NKIBHT.  1444,  PACE  14 


I 


KM 

NIV(NME)«2 

XHCTEP*>K0(  13)  41S82.0  ! 

IF  (XKCTCP.LT. 490. 0)THCN 

P  (NNC>  -C.  001  ♦$.  4444EXP (-O.  0044  XKH442) 


IF  (XHETER.LT.  1400.01  THIN 

POSO^O.  079*0. 487 4CXP  (-0.01 14XKH442) 


PCNMCX’0. 007*1. O444IXP(-0.C104XKH442> 

CN01F 

BNOIF 

C 

C44CALL  A8SPHH  TO  DCF  I VI  SKILL  MODERATORS  FOP  SROUMD-TO-AIR. 
C  VISUAL  DCTCCTION  TASKS 
C 

CALL  A*«*PHM(DXST.N!V.NNC.P.XH> 

80  TO  444 

c 

jCt'THIS  IS  AN  AIR-TO-AIR.  VISUAL  DCTCCTION  TASk 

28  NME-NMCM 
N1V(NME)«1 
P<MME>«DXBT(I> 

C 

C44CALL  RELPNH  TO  DCRIVf  SKILL  MODERATORS  FOR  AIR-TO-AIR. 

C  VISUAL  DCTCCTION  TASKS 
C 

CALL  RCLPMH(DIST.NIV.NNC.P.XN> 

00  TO  444 
C 

C44IHIS  TASK  INVOLVES  DETECT  I  NS  TARGETS  ON  A  DISPLAY 
C4  4XO  < 14) "LINE  RESOLUTION  ON  A  CRT 
C44DATA  FROM  OAT HAN.  1449.  PAGE  4 
C 

‘  24  HHE*NMt*l 

NIV(NME)-! 

P(NHE)"0. 904*0. 00024X0(14) 

C 

C44XC  < 1 > "NUMBER  OF  OPERATORS  ON  DUTY 
C44DATA  FROM  SCROUH  AND  LEHR.  1442.  PAGE  12 
C 


IM 
NIV(NNE)  "2 

IF  (XEU)  .EQ.  1.01  THEN 

P(NHE)*i .  40-0. 4404X0(3)  *0.  1304X0(3)442 
ELSE  , 

P (NME) »1. 0-0. 04 14EXP  (0.9444X0(3)  442) 
INOIF  I 


R-<?4 


W««UJI  I  UXMliUN  UN  UCMC&N 

CltMtA  NOI  91SSSL  AMO  ffBWWl,  I'm*  NM  13 

C 

mi  m»i 

*A  4X0419). 19.  t.0)A<NM8>-O.49 

If  <*0U9>  .10.2.0*  A <Nr®>-0.»4 

IA  4  X0U9>.t&.  3.0)  •<**«> -0.74 
If  4X04  19)  .19. 4.0)  A (»«> -0*77 
IA  «fOU9>  .ta.3.0)A<P#*»-0.40 
|1  4X0419) 

I A  l*0U9>  .10.  7.0)AtNH«>-0.  70 
17  410419). 10.9. 0)R4MN8i-0.90 
17  4*OU3>  .10.4.0>R4Nf«>-C.  79 

c 

CMXlt2>«*M0It*r  DRY  BULl  rtWTtlUT UNI  IN  OKUHECT  CKMT19M01 
C**DATA  Cl TfO  IN  HANCOCK*  IN  AH IM.  A I0UR1  4 

c 

Ml  111*1 
MlV  <NHE>— I 

A4)#«>-0.  727 *0.01 4* *«<2> -0.0002*  1142)  M2 
C 

C*4CALL  AMANH(0I9t.NXV.Nf«.A*XNI 
C 

CALL  A01AI1I<019T.N1V.NN1,A*XW> 

90  TO  444 
C 

CM  THR  TARGET  It  A4JCITORY  AND  VISUAL 
CMXHIN-U*S  ON  TASK  IN  HI NUT AS 

Ct *DA r A  FROM  SI131L.  ffEIfTM.  KOASTflN.  W2L90N.  ;*ND  OZKANTAtt *  1474*  RAOC  154 
C 

50  HAe«MM*-*l 

HlV<NNf.)-J 

XMIN»K0<3>  *40.  O 

A  ( ) -0 . 452-0 . 002 T  XH  |  N-^0 . 00003* 'i «  S  N4  •  2 

c 

CMCALL  AWRHM  TO  DCRIVf  i*IU-  HQ0CR4T0R9  AON  OmCTIMO  AUDI  TON  V 
C  ANO  VISUAL  TATOCTS 
C 

CALL  ADSRHNtDIST.NIV.NHf.R.XH) 

444  A* TURN 


tlfl - DETETHMDO.  IN.  N.  DIET.  I  TAM.  NTS.  Ml 

e 

c*  moduli  ihumam  factors  moderator  functions 
CHVMNII NORADS/VOLVHS  B.  10  00 
C 

CMMHNllMIl  ■JMOUTim  RSTURNE  T1HS-TO-OSTSCT  MODERATORS 
C  FOR  VI BUN1.  DETECTION  TOM 

e 

CtliWUT  KWHTWl 

c  too tMi  -  aoorcseine  information  for  n«  operator 

C  IDS (N)  -  MCNMNO  IMORPMTIOM  FOR  THE  SMVIRONnSMT 

C  I  TASK  -  AOOMKSSINS  INFORMATION  FOR  MS  TAB* 

C  N  -  INDEX  FOR  IDO  HMD  IDS 

C  NTS  -  INDEX  FOR  ITRBK 

c  aims:  -  nominal  task  parameters 

c  ui  mean 

C  121  STANDARD  deviation 

C  <31  DISTRIBUTION  TYPE 

c 

CFFOUrPVT  PARRMETERSl 

C  Mill  -  SKILL  CATE90RV  MODERATOR  VALUES 

C  Mill  p  DIFFERENCE  BETWEEN  DERIVED  AND  BAULINS 

C  REAM 

C  MM2I  »  DIFFERENCE  SEINE EN  DERIVED  AND  BASELINE 

C  STANDARD  DEVIATION 

C  Mill  •  DERIVED  DISTRIBUTION  TYPE 

C 

Cl  9 

CIILDCAL  VARIAELEll 

C  KO  -  NUMBER  OP  OPERATOR  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  KE  -  NUMBER  OP  ENVIRONMENTAL  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  NOOERATOR  FUNCTION 

C  NT  -  NUMBER  OF  TASK  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  NEO(KO)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  OPERATOR 

C  STATE  VECTOR 

C  NEE  (KE)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  ENVIRONMENT 

C  STATE  VECTOR 

C  NT  ASK  (NT)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  TASK  VECTOR 

C  NMF  -  HUMDER  OF  MODERATOR  EQUATIONS 

C  NIVU)  -  NUMBER  OF  INDEPENDENT  VARIABLES  IN  MODERATOR 

C  EQUATION  1 

C  fill  -  TIME  TO  COMPLETE  CALCULATED  FROM  MODERATOR 

C  EQUATION  I 

C 

Cl ID I MENS I ON  ARRAYS 

c 

DIMENSION  IDO(N).  IDE  IN) .  DI3T<3).  STASK (NTS) 

DIMENSION  NEO(IV).  NEE  <  4 )  •  NTSK(l).  NIV(IO).  TOO).  XM(3) 
DIMENSION  XE(4).X0(l?).XT6K(l> 

c 

CIIPEFII*  LENGTH  OF  ENVIRONMENTAL.  OPERATOR. 


L  MNb  I  MSA.  S'm'E  VELIUMI 

c 

•AT A  Kt/4/ 

9A»A  KS/14/ 

•AfA  NT/}/ 

C 

C»«DCFI9«  NOOKS  CUffNT  NUMBERS 

c 

SATA  NtI/4. 1,9.4/ 

SATA  NSO/3.  12.  40. 44.  14. 27. 37. 39,  34.  17. 90.91, 44, 93.  14. 20. 94. 99,47/ 
OAT  A  NT9K/4/ 

C 

CtiSKPltK  fHK  VECTOR  ELEMENTS 
C  XflU-AHSIEMT  NO! Ml  LEVEL  IN  09 

C  X8t2>H*v  BULB  TlMPfRATt#*  IN  DEORSftS  CSMTI9AA0K 
C  KK3)«VAAOA  PRESSURE  IN  m 
C  XC  1 4 » -NNMn  OF  0PCAAT0A9  ON  DUTY 
C  «0W> -OPERATOR'S  TIN* -ON- TASK.  IN  HOURS 
C  *0<2l-fAA9*T  TYPE 

C  X0<3> -HORIZONTAL  AANSE  TO  TAA9CT  tH  NAUTICAL  M1LC9 
C  XO  <  4  ►  —OPERATOR* 4  F If LD  OF  VI IN  IN  Ot9Rt£S 
C  XO<S>-T**OET  tACKOAOUPO  Ct*4*LEX!TV 
C  10  <  4*  — T4AOET /BACKGROUND  C0NTAA97  AAT10 
C  lOt/l-fAROET  Mil OH T  IN  FEET 
C  XO(9>«TAMirr  niotm  in  feet 
C  *g<4M*TAA0tT  DEPTH  IN  FEET 

C  X0«10>-f^**T  RAMOC  TO  TNAOCT  IN  NAUTICAL  MILES 
C  XO  C  11)  -flwCKONOUMD  NONTARBET  HEIGHT  IN  FEET 
C  Xntl2>«4AC*GAOUNO  NONTACNKT  WIDTH  IN  FEET 
C  I0U3I-0I9PLAV  AESr-LUTICN  IN  LINES 
c  xo u 4 >-oi stance  ra  d:»flay  in  feet 

C  X0<i3>*TAR©ST  COLOR 

C  X0<14>«NUMSCft  cf  background  characters 
C  *0(1 /^DISPLAY  KS l GHT  IN  FICT 
C  X0< IS>  — ©ISPLAV  NIOTM  IN  FEET 
C  X0<  )4>-LCCAU0N  OF  TARGET  ON  DISPLAY 
C  1TBKU>-TH*  OBSERVER -TJ- TARGET  POSITION 
C 

C$ •RETRIEVE  VALUES  FOR  OPERATOR.  ENVIRONMENTAL  AND  TANK  STATE  VECTORS 
C 

CALL  BET OVA  (200.  N.  NED.  NO.  XO) 

CALL  OCTEVA  COE.  N.  MCI.  KE.  XE) 

C 

CMMTSK  CONTAINS  ELEMENT  NUMBERS  OF  THE  TASK  EFECIFlC  HUMAN  FACTORS  DATA 
C 

IOPT-1 

CALL  OCTTSA  <ICRT. I TASK,  NTS.  NTS*.  NT,  XTSK) 

C 

C«t INITIALIZE  NMC.  NZV 
C 

NHE-0 

NIV(1)*0 

C 

CMEVALUATE  XM 

CMXTBK  ( 1>-THE  OBSERVER- TO- TARGET  POSITION 

C**NRO€-THE  OBSERVER- TQ- TARGET  POSITION  AS  AN  INTEGER  VARIABLE 
C 

NP08-NlNMXTBK<t>  > 

00  TO  <1.4.4. 7.9) NPOS 
C 

Ct • THIS  IS  A  GROUND-TO-GROUND.  VISUAL  DETECTION  TASK 
CMXQ<  1>-OPERATOR*3  TIME-ON-TACK  IN  HOURS 
C<*X0<2>— T ARGE T  TYPE 

Ci*DATA  FROM  AINSWORTH  AND  BISHOP.  1471.  PAGE  14 
C 

1  IF  <  XO (2) . LT. 1 t.O.OR. XO <2> . QT . 13.0)30  TO  2 


c*rri 


IC  A  TANK 


C 

I F  (X0(2>.tn.  lt.C>T(M«>-(:!S. 333-0.  It7tl0(lll/t0.0 

e 

CSSTAAtET  It  A  W 
C 

if  (iai2) .to.  j2.o>to**>-(3*.ooo-o.9ocxxo(1>>/ao.o 

c 

cxrxmcT  it  troofs 
c 

It  (XO<2>.tO.  13.0)  T(M)>(34. 000-1. OCOXXO(l)) /AC. 0 

e 

C*«X0(3)-H0RIZ0NTAL  RMNtt  TO  TAMCT  IN  NAUTICAL  MILES 
CMXYA*«>**«R1Z0HTAL  AANtt  TO  TAR9ET  IN  TAMM 
CMOAfA  FROH  KOtRICX.  1T7T.  FI SURE  2 

c 

2  KVAND»X0(3)  *2029.  SAT 

IF  1X0(2). LT. it. O.OR.IO(2>.t:. 29.0)90  TO  3 
IF  (X0(2). tT.  13.0.  AND. 10(2). LT. 28.0)00  TO  3 
IF  (10(2). BO.  13.0)90  TO  3 

WB-NWM 

MIV(»«>-2 

C 

CMTARfltT  IK  A  TAMC 

c 

IF  (XO(2).SO.  ll.0)TUF*.>-(2.119-l.A06«tXF(-O.O001»XVARD**2>>/A0.0 

c 

CMTAROST  It  A  JEEF 

c 

IF  (X0<2).Ca.!3.<,)T(NnC>»ll.4lt-1.0A*tCXFfO~00O4«XYriM>**2>>/A0.0 

c 

CMTAROET  It  AN  ARMORED  FERSONNEL  CARRIER 

c 

IF  <X0<2>  «B0.  I  A.O)  T IMRE)  — (0.043*0.  014XXVARD)  /  AO.  O 

c 

CMTARtET  It  A  TRUCK 

c 

IF  (X0(2).ra.  19.0) Tim»(«. 042*0. OlStXVARO) /AO. O 

c 

CMIAAOET  It  A  SOLDIER 

c 

IF  (X0(2)  . CQ.  29. 0)  T  (NMt  >  -  ( 1 .  961+0.  OOlfEXF  (0.0O07XX  VARDM2)  )  /40. 0 

c 

Cl (CALL  ABSTMM  OR  ftCLTMH  TO  DERIVE  SKILL  MODERATORS  FOR  SROUKD-TO-tROUND 
C  VISUAL  DETECTION  TASKS 

c 

3  IF  «**.EB.O)THEN 

T<NNE>-DI1TU> 

CALL  ftCLTMH<DX9T.NXV.NMt.T'XM> 

ELSE 

CALL  A*tTWH<DXST.NIV.NME.T.XH> 

EMOXF 
90  TO 

c 

CMTHIf  If  AN  AXP-TO-0POUND. VISUAL  DETECTION  TASK 
CtiX0<4)*THK  OBSERVES' f  FIELD-OF-VXEK  XN  DEGREES 
CMOATA  FROM  8CANLAN*  1476.  PAGE  *9 
C 

4  MME-NME+l 
NIV(NN€)-J 

t  *  HHE >  - '  T52.  230-2*4.  1 06t EXP '  -0 .  0021  XO  ( 4 )  •  t2>  >  / AO.  0 


l 

I 

1 


!V.' 


% 

\ 


,*v 


c 


L 

Ct t XO <9 > -TARGET  BACKGROUND  COMPLEXITY 
CttX0<6> -TARGET /BACKGROUND  CONTRAST  RATIO 
C^tDATA  FROM  BCANLAN.  1976.  PAGE  22 
C 

IP  <X0<2).LT. 11.6. OR. X0<2).0T. 19.0)00  TO  9 
IP  (X0(2>. OT.ll.O. AND. X0(2) .LT. 14.0)00  TO  9 
NHE-NHE+1 
NIVtNME)-3 
C 

Ctt TARGET  It  A  TANK 
C 

IP  (X0(2)  .EQ.  11. 0>T<NME>-<-39.  3274-32. 149$XQ<9>4- 32. 93BtX0<6>  >/60.0 
C 

Ctt TARGET  It  AN  ARMORED  PERSONNEL  CARRIER 
C 

IP  <X0 (2) .IQ.  14. 0) T <NME> - (01 . 303-2. 3001X0 (9) -36. 0771X0 (4) ) /60.0 
C 

Ci* TARGET  It  A  TRUCK 
C 

IP  <X0(2>.E0. 19.0>T<NME>-<-22.33l430.799*XO<S>-0.30?*XO<6>  >/60.0 
C 

CttCALL  ABSTMM  TO  DERIVE  SKILL  MODERATORS  FOR  AIR-TO-GROUND. 

C  VISUAL  DETECTION  TASK 
C 

9  CALL  AtSTHH(DIST.NlV.NME.T.XM) 

BO  TO  999 
C 

CttVHIS  19  A  GROUND-TO-AIR.  VISUAL  DETECTION  TASK 
CttXO< 7) -TARGET  HEIGHT  IN  FEET 
CttXO'S) -TARGET  WIDTH  IN  FEET 
C*t XO <9 ) —TARGET  DEPTH  IN  FEET 

Ct*XO< 10) -SLANT  RANGE  T0  TARGET  IN  NAUTICAL  MILES 
CMXFCET-ELANT  RANGE  TO  TARGET  IN  FEET 

Ct*X YARD-AVERAGE  OF  THE  TARGET'S  THREE  PLANAR  AREAS  IN  SQUARE  YARDS 
CttXHARC -ANGLE  THE  TARGET  SUBTENDS  IN  MINUTES  OF  ARC 
CttDATA  FROM  HAMMILL.  1981.  PAGE  D-t 

c 

6  NMB-WMEM 
Nl  V  <NME )  —4 

XPEET— X0< 10>  #6076. 1 
IF  (XFECT.EQ.O.O) XFEET-O. OOOOl 

XSYARD-<  <X0<7>  tX0<8>  )4-<x0<8)*X0<9)  )  ♦  <X0<7>  tX0<9> ) /3.0)  /9.0 
XMARC- <  XSYARDt  <  <3000. 0/ XFEET) t$2> >/0.2964 
IF  tXMARC. ST. 490.0) XMARC-4S0.0 

c 

CttTME  FOLLOWING  LINE  WAS  INSERTED  BECAUSE  THE  APPLE  XI  HAS  S  LIMIT 
C  ON  THE  SIZE  OF  EXPONENTS 
C 

T INME) •  <0.  4224-61  .t4'.'tEXP  <-0.  109*XMTRCt*2)  ) /60. 0 
C 

CttCALL  AMTMH  TO  DERIVE  SKILL  MODERATORS  FOR  GROUND-TO-AIR, 

C  VISUAL  DETECTION  TASKS 
C 

CALL  AB8TMH<DIST • NIV. NME. T . XM) 

00  TO  999 
C 

CttVHIS  IS  AN  AIR-TO-AIR.  VISUAL  DETECTION  TASK 
C 

7  NNZ-NMEM 
M1V<NME>-1 

T (NME) *D I ST  < 1 ) 

C 

CttCALL  RELTMH  TO  DERIVE  SKILL  MODERATORS  FOR  AIR-TO-AIR. 

C  VISUAL  DCTFXT10N  TASKS 
C 
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CAU.  RCLTWM0IST.N1V  NHt.T.XN) 

SO  TO  999 

C 

Cl*  THIS  TASK  INVOLVES  DETECT  I  NS  TARGETS  ON  A  DISPLAY 

CttXOClD-BACKOROIMD  NONTARCZT  HEIGHT  IN  FEET 

CIIX0(12>— BACKGROUND  N0NTAR8CT  WIDTH  IN  FEET 

CMXB  INCH-DIAMETER  OF  BACKGROUND  NONTAROET3  IN  INCHES 

CIIXTINCH-DIAMETER  OF  THE  TARGET  IN  INCHES 

C* *X INCH-DIFFERENCE  BCTNEEN  NONTAROET  AND  TARGET  DIAMETERS 

CIIDATA  FROM  BLOOMFIELD.  BECKWITH.  EMCRICK.  HARMURCK.  TCI. 

C  AND  TROUB.  1978.  PAGE  2 
C 

S  NME-HME+1 
NXV<NME>-2 

IF  <XOU1>.0T.XOU2>>THEN 

IF  (XO<12).Ea.O.O)XO(I2>«O.OOOOI 
XBXNCH-X0<11>/X0U2> 

ELSE 

XDXNCH-XO< 12)  /12.0 
ENOIF 

IF  <X0<7) . BT. XO<S> )THEN 
XTXNCH-X0<7>/12.0 

ELBE 

XTINCH-X0<S>/12.0 
END  IF 

XINCM-XBINCM-XTXNCH 

IF  (XINCH.EQ.O.O) XINCH— O. OOOOI 

T<NME>-a/<XINCHM2))/40.0 

c 

C**XO<13> -DISPLAY  RESOLUTION  IN  LINES  ON  A  CRT 
C»IXQ< 14 > -DISTANCE  TO  DISPLAY  IN  FEET 
CIIDATA  FROM  SCANLAN.  1976,  PAGE  IS 
C 

NME-NME+1 

NIV<NHE>-4 

IF  <XO<14) . EQ.O.O) XO ( 14) -O.OOOOl 

XBYARD—  <  <X0(7)*X0<8) )+<X0<8) IX0<9> >*<X0<7)IX0<9)) /3. 0) /9. 0 
XMARC-<XSYARDI<  <3000.0/X0 < 14) )II2) > /O. 2964 
T<NME>-<103.  324-2. 3791 XMARC-0.043IXO< 13)  >/60.0 
C 

CMXO  <  13) -TARGET  COLOR 

C**XO< 16) -NUMBER  OF  BACKGROUND  CHARACTERS 
CIIDATA  FROM  BLOOMFIELD.  BECKWITK.  EMERICK, 

C  MARMUREK.  TEI.  AND  TROUB.  197B,  PAGE  16 
C 

IP  <X0 MS)  .LE.2.0) THEN 
’  C 

Cl I TARGET  IS  WHITE  OR  TAN 
C 

NME-NME+1 
NIV  CNME) -2 

T  <NME)  -<9.942-2. 49 1 1X0  <  13)  +0. 00041X0 <  16)  >  /60. 0 
ENDXP 
C 

CIIX0<17>-DISPLAY  height  in  feet 
Cl 1X0 < IS) -DISPLAY  WIDTH  IN  FEET 
Cl 1X9 INCH* SEARCH  AREA  IN  SOLACE  INCHES 
CIIDATA  FROM  BLOOMFIELD*  BECKWITH.  EMERICK. 

C  MARMUREK.  TEI.  fiHD  TROUB.  197S.  PAGE  14 
C 

XtINCH-<XO <17)1X0 <1S))/ 144.0 
IF  <X0< IS) .LE.2.0) THEN 
NMK-NMC-M 
NIV  <NME>» J 

T<NME) -<-2.33341. 3661X0 < 13) +0. 020IXBINCH) /40. O 
ENOIF 
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Cl 


SUBROUTINE  FMABPHdDO.  IDE.  N.  DIET.  I TASK.  NTS.  XR> 


C  ••MODULE*  HUMAN  FACTORS  MODERATOR  FUNCTIONS 
C»tREFKW£HCEiMOPAOS/VOUJMI  9.10  OF 

c 

CttPUNFOSli  THIS  SUBROUTINE  RETURN*  PROBABILITY  TO  COMPLETE 
C  FINK  MANIPULATIVE  ABILITY  TASKS 

c 

CStSMFUT  FAA«MTt«IS» 


c 
c 
c . 
c 
c 
c 
c 
c 
c 
c 

C ••OUTPUT  PARAMETERS* 

C  XH<X>  -  St: IU.  CATKfXWv  MODERATOR  VALUES 


IDO(N)  -  ADDRESSING  INFORMATION  FOR  THC  OPERATOR 

IOC  <N>  -  AOQAfcSBlNO  INFORMATION  FOR  THC  ENVIRONMENT 

I  TASK (NTS)  -  ADCRCSSXNB  INFORMATION  FOR  THC  TASK 

N  *  INDEX  FOR  100  AND  I  DC 

NTS  -  INDEX  FOR  XT  ASK 

OUT (3)  *  NOMINAL  TASK  PARAMETER* 

Cl)  m AN 

(2)  STANDARD  DEVIATION 
C3>  DISTRIBUTION  TYF€ 


XHt  1 1 


DIFFERENCE  BETWEEN  C*.»  I  VCD  AND  BASELINE 
HCAN 

1NC2)  •  DIFFERENCE  EE T KEEN  DERIVED  AND  BASELINE 
STANDARD  DEVIATION 
«N<3)  •  DERIVED  DISTRIBUTION  TYPE 


C 

c 
c 
c 
c 
c 

Cm 

Ct •LOCAL  VARIABLES* 

C  KO  -  NUm«R  OF  OPERATOR  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  )I  ‘  NUHSCR  CF  ENVIRONMENTAL  INDEPENDENT  VARIABLES  USED  IN 

THIS  MODERATOR  FUNCTION 

NT  -  NUMBER  OF  TASK  INDEPENDENT  VARIABLES  USED  IN 
THIS  MODERATOR  FUNCTION 

MK>(KO)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THC  OPERATOR 
STATE  VECTOR 

NEE  IKE)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  ENVIRONMENT 
STATE  VECTOR 

N I  ASK  (NT)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  TASK  VECTOR 
NNC  -  HUMBER  OF  MODERATOR  EQUATIONS 

NIV(I)  -  NUMCCR  OF  INDEPENDENT  VARIABLES  IN  MODERATOR 
EQUATION  X 

PCI)  -  PPOBABlLl TY» TO- COMPLETE  CALCULATED  FROM  MODERATOR  EQUATION  I 


C 

c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 

C* •DIMENSION  ARRAYS 

c 

DIMENSION  IDO (N) .  1DC<N).  DISKS).  1  TASK (NTS) 
DIMENSION  NEO  ( 1 )  .  NEEM).  NIV(X).  Ptl).  XN(3> 
0 1  MENS  1  ON  XOU).  XK(X) 

c 

C* •DEFINE  mXDCD  ELEMENT  NUMBERS 
C 
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UMtrt  MfcU/J/ 

DATA  mi/7/ 

DATA  N1V/2/ 

DATA  KX.KQ/I.l/ 

C 

CttTX  VECTOR  ELEMENTS  ARC  AC  POL LOME I 
C  IOU>-TIHC  OH  TASK  IN  HOURS 

C  XEU^SPtTZCAL  VIBRATION  IN  M2 

C 

C» •RETRIEVE  THC  VALUE!  FOR  TV*  fTATf  VECTORS  . 

C 

CALL  OCTOVA  <  IDO.N.NCO.  KO.  XO) 

CALL  BCTCVA  <  IDC. N.  NEC. fct.  XE> 

c 

C*f INITIALIZE  nhe 

c 

NMC-0 

c 

C* •EVALUATE  XM 

C««DATA  FROM  PFEIFFER  ET  AL  «1*7*> 

C 

IFUiU>!oT.2.0>  T HEN 

c 

C«*  VIBRATION  IB  PRESENT 
C 

P<MHE>*1.0-<  (l.O-DI ST (I)  )  •  (•  71S+. S23XCXP f  ~,O13XX0 ( 1 )  ))  ) 

C 

ELSE 

C 

c«t  HO  VIBRATION  It  PRESENT 
C 

P  (HMC)  •! .  O-  <  a  .  O-DIfT  <  l  >  )  •  <  1 . 23-.  343* EXP < 03A«X0 <!  )  >  >> 

EMDIF 

C 

C 

CMCALL  RELPMH  TO  DERIVE  SKILL  MODERATORS  FOR  PROBABILI TV-TO-CONPLETE 
C 

CALL  RELPMH (DI ST. NI V.NME.P.XM) 

RE  TURN 
END 
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Cl 

•UMOUTINI  rmiTHdOO.  I DC.  N.  D1ST.  I  TACK.  NTS.  KM) 

c 

C« •MODULE* HUMAN  FACTORS  MODERATOR  FUNCTION® 

CMRL.FERENCE*  MOPADS/VOLUME  3.10  DF 
C 

CMPURP0BC*THI1  SUBROUTINE  RETURNS  TIME  TO  COMPLETE 
C  TASK®  WHICH  REQUIRE  FINE  MANIPULATIVE  ABILITY 

C 

CM  INPUT  PARAMETERS* 

C  XDO(N)  -  ADDRESSING  INFORMATION  FOR  THE  OPERATOR 

C  IDE (N)  -  ADDRESSING  INFORMATION  FOR  THE  ENVIRONMENT 

C  P ASK < NTS)  -  ADDRESSING  INFORMATION  FOR  THE  TASK 

C  N  -  INDEX  FOR  IDO  AND  IDE 

C  NTS  -  INDEX  FOR  I TASK 

C  DIST (3)  -  NOMINAL  TASK  PARAMET l *8 

C  U>  MEAN 

C  (2)  STANDARD  DEVIATION 

C  <3)  DISTRIBUTION  TYPE 

C 

CM  OUTPUT  PARAMETERS* 

C  XM(I)  -  SKILL  CATEGORY  MODERATOR  VALUES 

C  XM < 1 >  •  DIFFERENCE  BETWEEN  DERIVED  AND  BASELINE 

C  MEAN 

C  XK'2)  •  DIFFERENCE  BETWEEN  DERIVED  AND  BASELINE 

C  STANDARD  DEVIATION 

C  Xh<3)  -  DERIVED  DISTRIBUTION  TYPE 

C 

Cti 

CM  LOCAL  VARIABLES* 

C  KO  •  NUMBER  OF  OPERATOR  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  KE  -  NUMBER  DP  ENVIRONMENTAL  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  NT  -  NUMBER  OP  TASK  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  NEO(KO)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  OPERATOR 

C  STAT  VECTOR 

C  NEE (KE)  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  ENVIRONMENT 

C  r  »TE  VECTOR 

C  NTASK '  IT)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  TASK  VECTOR 

C  NHC  -  NUMBER  OF  MODERATOR  EQUATIONS 

C  NX’  i)  -  NUMBER  OF  INDEPENDENT  VARIABLES  IN  MODERATOR 

C  EQUATION  I  I 

C  ;(!>  -  TIME  DELAY  CALCULATED  FROM  MODERATOR  EQUATION  I 

C 

C ••DIMENSION  ARRAYS 

c 

DIMENSION  IDO (N) •  IDE<N).  DIST<3>.  ITASK (NTS) 

DIMENSION  NEO  <3) .  NEE  ( 1 )  .  NI7U).  T<1).  XM<3) 

DIMENSION  XE < 1 ) •  XO (3) 

C 

C ••DEFINE  THE  LENGTH  OF  STATE  VECTORS 
C 
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DATA  rt.KO/1.3/ 

c 

CMDEF1NE  ELEMENT  CUMBERS 

c 

DATA  NEZ/1/ 

DATA  NE3/67 . 44. A9/ 

DATA  NIV/1/ 

C 

C«»THE  VECTOR  ELEMENTS  ARE  AS  FOLLOWS  I 
C  Xt(l>-AMBIENT  (DRV  BULB)  TEMPERATURE 

C  XO  1 1 )  -SKIN  TEMPERATURE  WHEN  THE  OPERATOR  CHANGED  ENVIRONMENTS 
C  (OLD  SKIN  TEMPERATURE I 

c  xo<2)«time  in  the  Current  temparature 

c  xo (3) "Current  skin  temperature  (computed  prom  xou>  and  xo<2>> 

c 

c 

cmretrievc  values  for  the  state  vectors 

c 

CALL  GSTEVAdDE.N.NEE.KE.  XE> 

CALL  OCTOVA(IDO.N.NEO.KO.XO) 

NME-0 

•c 

C 

CMEVALUATE  XM 

c 

NME"NMC«1 

C 

CMDATA  FROM  SIEGEL  ET  AL.  1*7* 

CMFINAL  SKIN  TEMPERATURE  EVALUATION  FROM  MCINTYRE  (1780) 

CMRATE  OF  SKIN  TEMPERATURE  CHANGE  ( 1-EXP ( . 03«X0 (2) )  IS  HYPOTHESIZED 
C 

C  EVALUATE  SKIN  TEMPERATURE  (XO(3>> 

C 

X0(3>-X0d>*((2A.lS+.233iXEd>>-X0d>>«d-EXP(.0S«X0(2>>> 

c 

C  EVALUATE  TIME  BASED  UPON  SKIN  TEMPERATURE 
C 

T(l>"DIST(l>*(t.O/(1.0t2-.607«EXP(-.003*XO(3)*(£>) ) 

C 

C  ENSURE  THAT  HE  DOES  NOT  00  FASTER  THAN  AVERAGE  BECAUSE  HIS 
C  HANDS  ARE  WARM 

c 

IF  (T(I).LT.DIST(D)  T(1»-DIST(1> 

C 

CMCALL  RELTMH  TO  DERIVE  SKILL  MODERATORS  FOR  TIME  TO  COMPLETE 
C 

CALL  RELTMH(D!ST.N1V.NM€.T.XM> 

RETURN 

END 
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C  "DIMENSION  ARRAYS 
C 

DIMENSION  IDO (N) . 
DIMENSION  NIV(l) . 
C 

CMINITIALIZE  NME.NIV 
C 

MMf-O 


IDC(N).  DI3T  <  3  > .  IT ASX (NTS) 
PU?.  XM(3> 


]8  i*| 

m  iv 

4 

sM 

at.-  A 

kt  ft 


M  *3 


SUBROUTINE  QPCFPH (IDO.  IDE.  N.  DIST.  I  TASK.  NTS.  XM) 

C 

C« 'MODULE* HUMAN  FACTORS  MODERATOR  FUNCTIONS 
C"  REF  ERENCElMOPADS/ VOLUME  3.  10  DF 
C 

CMRURPOSEi  THIS  SUBROUTINE  RETURNS  PROBABILITY  TO  COMPLETE 
C  GENERAL  PHYSICAL  EFFORT  TASKS 

C 

C" INPUT  P^AMETEPS* 

C  IDO <N)  -  ADDRESSING  INFORMATION  FOR  THE  OPERATjR 

C  I  DC  <N>  *  ADDRESSING  INFORMATION  FOR  THE  ENVIRONMENT 

C  It  ASX (NTS)  *  AODRES82NG  INFORMATION  FOR  THE  TASK 

C  N  -  INDEX  FOR  IDO  AND  IDE 

C  NTS  -  INDEX  FOR  I TASK 

C  OIST (3)  -  NOMINAL  TASK  PARAMETERS 

C  it)  MEAN 

C  (2)  STANDARD  DEVIATION 

C  (3)  DISTRIBUTION  TYPE 

C 

C "OUTPUT  PARAMETERS* 

C  XM ( I )  -  SKILL  CATEGORY  MODERATOR  VALUES 


C  XM < 1 )  •  DIFFERENCE  BETWEEN  DERIVED  AND  BASELINE 

C  MEAN 

C  XM (2)  •  DIFFERENCE  BETWEEN  DERIVED  AND  BASELINE 

C  S T ABOARD  DEVIATION 

C  XM<3>  •  DERIVED  DISTRIBUTION  TYPE 

C 

Cl  i 

C "LOCAL  VARIABLES* 

C  KO  -  NUMBER  OF  OPERATOR  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  Kf  -  NUMBER  OF  ENVIRONMENTAL  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  NT  -  NUMBER  OT  TASK  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  HEX) (KO)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  OPERATOR 

C  STATE  VECTOR 

C  NEI(KE)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  ENVIRONMENT 

C  STATE  VECTOR 

C  N TASK (NT)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  TASK  VECTOR 

C  NME  -  NUMBER  OF  MODERATOR  EQUATIONS 

C  NIV<!>  ~  NUMBER  Oh  INDEPENDENT  VARIABLES  IN  MODERATOR 

C  EQUATION  1 

C  P(I)  -  PROBABILITY-TO-COMPLETE  CALCULATED  FROM  MODERATOR  EQUATION  I 
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Cl 

SUBROUTINE  GPEFTMdDO.  IDE.  N.  DX8T.  XTASK.  NTS,  XH> 

C 

C ( (MODULE i HUMAN  FACTORS  MODERATOR  FUNCTIONS 
C( (REFERENCE* HOP AD8/ VOLUME  S.  10  DF 
C 

C( (PURPOSE i THIS  SUBROUTINE  RETURNS  TIME  TO  COMPLETE 
C  TASKS  WHICH  REQUIRE  GENERAL  PHYBICAL  EFFORT 

C 

C(( INPUT  PARAMETERS* 

C  IDQ(N)  -  ADDRESSING  INFORMATION  FOR  THE  OPERATOR 

C  IDE (N)  -  ADDRESSING  INFORMATION  FOR  THE  ENVIRONMENT 

C  I TASK (NTS)  -  ADDRESSING  INFORMATION  FOR  THE  TASK 

C  N  -  INDEX  FOR  .DO  AND  IDE 

C  NTS  -  INDEX  FOR  I TASK 

C  D18T (3>  -  NOMINAL  TASK  PARAMETERS 

C  ( 1 >  MEAN 

C  (2)  STANDARD  DEVIATION 

C  (3)  DISTRIBUTION  TYPE 

C 

CttOUTPUT  PARAMETERS* 

C  KM < I )  -  SKILL  CATEGORY  MODERATOR  VALUES 

C  XMU)  -  DIFFERENCE  BETWEEN  DERIVED  AND  BASELINE 

C  MEAN 

C  XM (2)  -  DIFFERENCE  BETWEEN  DERIVED  AND  BA6ELXNE 

C  STANDARD  DEVIATION 

C  XM<3>  •  DERIVED  DISTRIBUTION  TYPE 

C 

Cl  i 

C( (LOCAL  VARIABLES! 

C  KO  -  NUMBER  OF  OPERATOR  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  KF  -  NUMBER  OF  ENVIRONMENTAL  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  NT  -  NUMBER  OF  TASK  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  NEO(KO)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  OPERATOR 

C  STATE  VECTOR 

C  MCE(KE)  -  ELE'.IENT  NUMBERS  OF  VARIABLES  IN  THE  ENVIRONMENT 

C  STATE  VECTOR 

C  N TASK (NT)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  TASK  VECTOR 

C  NHE  -  NUMBER  OF  MODERATOR  EQUATIONS 

C  NIV(I)  -  NUMBER  OF  INDEPENDENT  VARIABLES  IN  MODERATOR 

C  EQUATION  I 

C  r(l)  -  TIP-  DELAY  CALCULATED  FROM  MODERATOR  EQUATION  I 

C 

C( (DIMENSION  ARRAYS 
C 

DIMENSION  IDO(N).  IDE(N).  DX5T(3).  ITA3K (NTS) 

DIMENSION  NEO (4).  NEE (2) .  NTSK(l).  NIV(3>.  T(3),  XM(3> 
DIMENSION  XE (2) •  XQ(4).  XTSK(l) 

C 

C( (DEFINE  THE  LENGTH  OF  STATE  VECTORS 
C 
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Ml*  KK.fcU.NI/4.4.l/ 

e 

citwiw  element  mm 
c 

DATA  NEE/I. D/ 

DATA  NE0/S.8.24.JD/ 

DATA  NTW/t  > 

DATA  MAC. HIV/3. 2. 3. 2/ 

C 

cnna  vector  elewntd  arc  ad  follow*! 

C  IE(I>-ANSIENT  (DAY  DULD)  TEHPERAW« 

C  XE(2l-ATH0*PHtRIC  VAPOR  PRESSURE  IN  HD 
C  I0I1KIMTH  OF  OPERATOR'S  PREVIOUS  NORK  USD  I  ON 

C  X0(2>«LtMDTH  OA  OPERATOR'S  PREVIOUS  AMT  KHION 

C  XO(3>*YOJRS  OF  SLEEP  TAD  OPERATOR  RECEIVED  IN  MMT  RECENT  SLEEP 

C  XO(«)-OAVt  IOA  PART  C*  A  DAY)  SINCE  TW  OPERATOR  LAW  SLEPT 

C  XTSK<II«*CAL/HINUTI  AMU  INKS  DV  TWC  TADK 

c 

c 

C44RETRIEVE  VALUE*  ran  t.«  dtatv  wctors 

c 

CALL  MTEVAdDE.N.NEE.KE.XE) 

CALL  SETOVA  ( I  DO.  N.  MEQ. KO.  X0> 

CALL  OETTSAOTADK.MTS.NTSK.NT.XTIBO 

c 

c 

CMBVALUATE  XM 

C 

C 

C«»FROM  HCINTYRE  (|»DO>,  FADE  32*  RELATING  TO  FHYDIOLODICAL  MEAT 
C  EXPOSURE  LIMIT  <FMEL> 

^relationship  between  time  on  task.  phiI.  am  time 

C  TO  FEFFOAM  TtE  TASK  HAS  HYPOTHESIZED 

c 

c 

C  COMPUTE  HtTASOLIC  WORK  RATE  PAOM  KCAL/MIH  (APPROXIMATION) 

C 

AM-3. 0*32.  KXTSKU) 

C 

C  COMPUTE  MET  DULD  SLOW  TEMPERA TUAE 
C 

W88T-. S47XXE ( 1 >  *  .2I*«XE(2>  *  3. 3D 
C 

C  ENSURE  THAT  AM  AND  HBGT  ARE  WITHIN  ACCEPTABLE  BOUNDS  POM  THE 
C  PHCL  FORMULA  TO  BE  VALID 
C 

IF (AH. 0T. 83.0  .AND.  AM. LT.  190.0  .AND.  HBST.ST.31.0  .AND. 

♦  NBOT. LT. 30. )  THEN 

PHCL-U7.2SII0.0«tS  -  12.Y7tRHtl0.0t**  *  18.  At  •  <  RM*«2> 

*  I10.0M3)  t  INBGTt*(-.S3*)  > 

c 

C  AS  THE  OPERATOR  APPROACHES  H1B  PHEL.  H1B  PERFORMANCE  TIME  SHOULD 
C  INCREASE  SLIUHTLY  (CONSIDERING  HIS  RECENT  REST) 

C 

T(I>-DIBT(1) t (1.0»(X0(1)-X0(2)  I/PHEL) 

else 

rtn-oxsKi) 

tNOir 

c 

c 

Ctt  MODEL  F*OH  PFEIFFER  ET  AL  <197P> 

CM  THE  LINK  BETWEEN  REST  REQUIREMENT  AND  PERFORMANCE  18  HYPOTHESIZED 
C 

C  COMPUTE  THE  REST  REQUIREMENT 
C 


RESTR»<  <X0s;>-X0<2> ) t ( a?BK < 1 > ~4.S> > / 'XT0K <1 >~1 • S> 
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if  tmr tm.lt. o.ot  nnwi.o 


•  Mm  fm cm  Siam,  «t  «l 

COXUTB  IX  MUM  IM.  MMS  UPC*  TX  Tint  81NCC  TX 
ONMtW  LMT  tLtrr 

IP  IXO(4>.LT.O.Zl>  FT»«O.3O*l0«4l 

IF  IMUi.MI.0.2*  .AMO.  10 (4) .  LC.  0.  C3>  FTM-0.3*!. 44(10(4) 
IF  (BOMU.aT. 0.031  FTM0.82*«.044(10<4) 

1NCMCMC  IX  FftTIM  LCVCL  IF  TX  OPCMATTJM*a  LMT  0L4EXF  UA4 
LIN  THMM  ■  HOUR* 


IF(X0t3>  .OT.C.OI  IXN 

FMNNI.0 

tLt 

P4TMCD-0.  '23(X0(3> 

■NOXF 

IF  (F4TMC0.LT .0.001)  PMTMCO-O.OOt 

ftmfto/fmtxo 

DWC  TNMT  TX  F4TIM  ICMK  DOM  NCT  CXCCXS  1.0 
IF  (FTa.CT.t.O)  FT0-1.0 
IHCMCAM  TX  OPERATOR*  B  TMK  PERFORM****  TIX 
T(3)«0I*T<I>(tt.O*FTO> 

4  CALL  MCLTnM  TO  OCR  I  VC  IK  ILL  MODEAATOaa  FOM  TIX  TO  COMPLETE 
C 

CALL  XLTMMIDIST.NIV.NX.T.lfl) 

XTUMN 


subroutine  qnwmcido.  id*.  n.  otrr.  itmsk.  nts.  «u 


c 

c««mooulc<hu**m  factors  mtwcrator  functions 
CMfVmDdif*OMM/VQUltt  9.IO  OF 

c 

c»iW«iiTHii  susnoutm  returns  wmiiity  to  complete 
c  mom  manipulative  tasks 

c 

CF* INPUT  PARAMETERS! 

C  1 00(H)  -  ADDRESS  l  INFORMATION  FOR  THE  OPERATOR 

C  XOC  <M>  -  ADDRESS I N8  INFORMATION  FOR  ?►«  EMVXRO»A«NT 

C  IlASKCNTS)  -  ADDRCSSIM8  INFOPmTION  FOR  THE  TASK 

C  H  -  INDEX  FOR  100  AND  IOC 

C  NT*  -  XNOCX  FOR  I  TASK 

C  DI§T<3>  -  NON  INAL.  TACK  PARAMETERS 

C  <4>  mean 

C  <2>  STANDARD  DCVXATXON 

r,  (3)  DISTRIBUTION  TYPE 

C 

CTtOUTAUT  PARAMETERS! 

C  Xmi)  -  SK  ILL  CATFOORY  MODERATOR  VALUES 

C  XM<1)  -  DIFFERENCE  BETWEEN  DERIVED  AND  0A9CLSMX 

C  MEAN 

C  XH<2>  •  DIFFEREMCfc  BETWEEN  OCA I VCD  AND  OACCLXNC 

C  STANDARD  DEVIATION 

C  XN<3>  -  DERIVED  DISTRIBUTION  TYRE 

C 

C»l 

CtILOCAL  VARIABLES* 

C  KO  -  NUMBER  OR  CTE-ATOR  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  MOOERATL*  FUNCTION 

C  Kt  -  NUMBER  OF  ENV I RONMENT AL  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTIO ? 

C  NT  -  NUMBER  OF  TASK  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  NEO(KO)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  OPERATOR 

C  STATE  VECTOR 

C  NEE(KE)  -  ELEMENT  NUMBERS  OF  VARIABLES  M  THE  ENVIRONMENT 

C  STATE  VECTOR 

C  NT ASK (NT)  -  ELEMENT  NUMBER-*  OF  VARIABLES  IN  TKE  TACK  VECTOR 

C  NME  -  NUMBER  OF  MODERATOR  EQUATIONS 

C  MIV(X>  -  NUMBER  OF  INDEPENDENT  VARIABLES  IN  MODERATOR 

C  EQUATION  I 

C  P(I)  -  PROBADILITY-TO-COMPLETE  CALCULATED  FROM  MODERATOR  EQUATION  I 

C 

CMDIMENSION  ARRAYS 
C 

DIMENSION  IDO (N) •  IDE  <N) .  DIST<3>.  ITASK (NTS) 

DIMENSION  NIVU).  P<1>.  XM<3> 

C 

C«f INITIALIZE  NME. NIV 
C 


MMF*0 


:S  S3 

y. 


Cl 


luMUTM  smmathuog.  in.  dibt.  it ask.  nrt.  mi 


ClMOOULliMUWN  FACTORS  HOC*MATOR  FUNCTIONS 
CMKHWaiNONN/VGUM  5.10  OP 

c 

ci«*u^on«mti  subroutine  rxm  to  amm 

c  tam  which  rcouirs  meat  manipulation 

c 

Ctt INPUT  P*AAT«TCRli 

c 
c 
c 
c 
c 
c 
c 
c 
c 
c 

CitOUmjT  PARAM ITSWt 

C  IH<t)  -  He  ILL  CATEGORY  MODERATOR  VALUES 


100  tN)  -  A0OPCSSIN9  INPOANTiai  EON  THS  OPERATOR 
IDClMI  -  AOORCMINO  IMP  OMIT  ION  EON  THE  ENVIRONMENT 
!(***<  NTS)  -  AOONEMIWO  1  FORMAT  ION  EUR  THE  TAB* 

N  -  INDEX  EON  100  ANO  IOC 
NT«  -  INDEX  EON  HAS* 

DIET  (3)  -  NOMINAL  TASK  fWWETDUl 
U> 

12) 

<3) 


ETANOANO  DEVIATION 
DISTRIBUTION  TYPE 


XN(D  •  DIFFERENCE  BETWEEN  DERIVED  ANO  EASEL  I  HE 
MEAN 

*M<2>  •  OIEFENCNCE  BETWEEN  OCNIVEO  ANO  BASELINE 
BTANOAND  DEVIATION 
XHI3I  -  OCNIVEO  DISTRIBUTION  TYPE 


C 

c 
c 
c 
c 
c 

Clt 

C if LOCAL  VANlADLESi 

C  KO  -  NUMBER  OF  OPERATOR  INDEPENDENT  VAN I ABLER  USED  IN 

C  THIS  MODERATOR  FUNCTION 

KI  -  NUMBER  OE  ENVIRONMENTAL  INDEPENDENT  VARIABLES  USED  IN 
THIS  MODERATOR  FUNCTION 

NT  -  NUMBER  OF  TASK  INDEPENDENT  VARIABLES  USED  IN 
THIS  MODERATOR  FUNCTION 

NEO(KO)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  OPERATOR 
STATE  VECTOR 

NEE(KE)  -  CLEMENT  NUMBERS  OF  VARIABLES  IN  THE  ENVIRONMENT 
STATE  VECTOR 

N TASK (NT)  -  ELEMENT  NUMBER*  OF  VARIABLES  IN  THE  TASK  VECTOR 
NME  -  NUMBER  OF  MODERATOR  EQUATIONS 

NIV< I >  -  NUMBER  OF  INDEPENDENT  VARIABLES  IN  MODERATOR 
EQUATION  I 

Til)  -  II ME  DELAY  CALCULATED  FROM  MODERATOR  EQUATION  X 


C 

c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 

Cf fD I MENS I ON  ARRAYS 

c 

DIMENSION  TDO  <N) • 
DIMENSION  NIV(l), 
C 

Ctf INI TIALXZE  NME.N1V 

c 

l#1E*0 


IDE (N> •  OXST  <3> •  ITA9K  <NT3) 
Til).  XH(3> 
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C**tV«U*Tt  l« 

C««NO  6*T*  MCW  POUND  TO  PREDICT  TINE  TO  COfftlCTC  TAOKO  MHtCH  NEOUlftK 

ctt  man  fWMiPuu* tiom 

W€H<*1 

NtVM)*| 

T<t*K>*OItT<l> 

C 

C99QMLL  mLim  fO  OCAIW  »!u.  HOCCKATOftf  PON  TJI*  TO  COMPVET* 

C 

CALL  Ml.rKH(OItr.NlV.ra«.T»KK) 

RCTORN 


h 


c. 


i 


Ct 


SUBROUT INC  LMSYPHCIDO.  IOC.  N.  DXST.  I  TASK.  NTS.  KM) 


c  ?  •, 

1/  *  - 

O 

. 

►,  « 
1  •  .* 
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Ct •MODULE) HUMAN  FACTORS  MODERATOR  FUNCTIONS 
C« •REFERENCE iMOPADS /VOLUME  5.IO  OF 
C 

CMPUHPOSCi  THIS  SUBROUTINE  RETURNS  PROBABILITY  TO  COMPLETE 
L  LONG  TERM  MEMORY /SENSORY  TASKS 

C 

cm  input  parameters i 


100(H)  -  ADDRESSING  INFORMATION  FOR  THE  OPERATOR 
IDE <N)  -  ADDRESSING  INFORMATION  FOR  THE  ENVIRONMENT 
llt«K<Nfft>  -  ADDRESSING  INFORMA I  ION  FOR  THE  I  ASK 
H  -  INDEX  FOR  IDO  AND  IDE 
MIS  *  INDEX  F OR  1  I ASF 
DISKS)  -  NOMINAL  TASK  PARAMETERS 
(I)  MEAN 

U)  STANDARD  DEVI A f ION 
<S>  DISTRIBUTION  TYRE 


L 
C 
C 

c 
c 
c 
c 

L 
l 
L 

lm  output  parameters* 

c  *Ht i >  -  •> ill  category  moderator  values 

t  MMIl)  •  DIFFERENCE  DC  I  WEEN  DERIVED  AND  BASELINE 

L  MEAN 

C  XM<2>  -  DIFFERENCE  DC  T WEEN  DERIVED  AND  BASELINE 

t  STANDARD  DEVIATION 

L  IM(S>  •  DERIVED  DlftlRlBUT ION  TYRE 

C 

C«  f 

(.••LOCAL  VARIABLES! 


KO  NUMBER  OF  OPERATOR  INDEPENDENT  VARIABLES  USED  IN 
THIS  MODERATOR  FUNCTION 

IE  -  NUMBER  OF  ENVIRONMENTAL  INDEPENDENT  VARIABLES  USED  IN 
IMIS  MODERATOR  FUNCTION 

HI  -  NUMBER  OF  IASI  INDEPENDENT  VARIABLES  USED  IN 
THIS  NQOCRAIQR  FUNC1I0N 

t*0<KU>  -  ELEMCM1  NUMBERS  OF  VARIABLES  IN  THE  OPERATOR 
STAiE  VECTOR 

NEE  (►*>  -  EL  at  HE  H  ?  NUMBERS  OF  VARIABLES  IN  THE  ENVIRONMENT 
STATE  VICTOR 

Ml  W®F (NT )  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  TASK  VECTOR 
-  NUMBER  OF  MODERATOR  EQUATIONS 

NIV(I)  -  NUMBER  OF  INDEPENDENT  VARIABLES  IN  MODERATOR 
COURT  ION  I 

RU )  -  PAOOADILITV- TO -COMPLETE  CALCULATED  FROM  MODERATOR  EQUATION  J 


C 

c 
t 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 

L ••DIMENSION  t*RAYf 
L 

DIMENSION  IDO  (N)  .  IDE  (N)  .  DISKS).  1  TASK  (NTS) 
DIMENSION  NEC  (2)  .  NIVU).  Pl|).  imD 
DIMENSION  10(2) 

c 

CttDCFINE  NEEDED  ELEMENT  NUMBERS 

C 

RAIrt  ICO  'MS.6«' 
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UMIM  NtV/y/ 

DATA  KO/2. 

c 

C*t  THE  VECTOR  ELEMENTS  ARE  Afi  FOLLOWS 

C  XOtD-NUMDCR  OF  TIMES  THAI  THE  OPERATOR  HAS  PREVIOUSLY  performed 

C  TIE  TASK 

C  «0(2)«0PCRAT0R’S  SENSE  OP  DIRECTION 

C 

C 

CMRETRIEVE  THE  VALUES  OP  TFK  STATE  VECTORS 
C 

CALL  GETOVA  (irO.N.NEO.KO.XO) 

c 

CTTINI  I  lAi.WE  NME 

c 

NME-V 
C 

Cf DEVALUATE  «M 
C  * 

CTTDAIA  FROM  EIEOEL  ET  AL.  197* 

C 

IF  1X0(2) .CO. 1>  THEN 
C 

C  OPERA10R  HAS  A  GOOD  DENSE  OP  DIRECTION 
C 

P(NH£>»D1ST  (I  >  *  (.414-.  749«EXP(-.22*(X0<I>  M2)  > 

ELSE 

C 

C  OPERA  *  OR  MAS  A  POOR  SENSE  OP  DIRECTION 

t 

P<NME)-DIST ( I ) 

END  IF 
C 

C*«CALL  RELPMM  10  DEPIVE  SKILL  MODERATORS  FOR  PRQRABILIT  V-TO-CONPLETE 
L 

CALL  RELPMH'DISI .MJV.TME.R. XM) 

RETURN 

END 

f 
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SUDPOU11NC  LHSY1HUD0.  I  DC.  M.  DIET.  ITM6K.  NTS.  XH) 
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CttMOtHJLE*  HUMAN  FACTORS  MODERATOR  FUNCTIONS 
Ci tREF ERENCE » NOPADS/ VOLUME  S.  10  Df 
C 

CfFPUPPOSE*  IMIS  SUBROUTINE  RETURNS  TINE  TO  COMPLETE 
C  TASKS  WHICH  REQUIRE  LONG  TERM  MEMORY /SENSORY 

c 

Lit  INPUT  PARAMETERS* 


IDUtNT  -  ADDRESSING  INFORMATION  FOR  THE  OPERATOR 
IDE  IN)  -  ADDRESSING  INFORMATION  FOR  TML  ENVIRONMENT 
I  I ASK (NTS)  -  ADDRESSING  INFORMATION  FOR  THE  TASK 
N  -  INDEX  FOP  IDO  AND  IDE 
NTS  -  INDEX  FOR  11 ASK 
Dili (3)  -  NOMINAL  TASK  PARAMETERS 
U>  MEAN 

(2>  STANDARD  DEVIATION 
<3>  D1STRIBUT ILN  TYRE 


C 

r. 

c 

L 
C 
c 
c 
c 
c 
c 

€♦♦00 I PUT  parameters* 

t  xmi>  -  SKILL  CATEGORY  ‘10DERAT0R  VALUES 

L  XMU>  -  DIFFEF^NCE  BETWEEN  DERIVED  AND  BASELINE 

C  MEAN 

C  XM<2)  •  DIFFERENCE  BETWEEN  DERIVED  AND  BASELINE 

C  STANDARD  DEVIATION 

C  XM  <3)  •  DERIVED  DISTRIBUTION  TYPE 

C 

Cn 

LM  LOCAL  VARIABLES* 


KE 


NT 


*»  . - 
.  ,V 


t 

c 

C 
C 

c 
c 
c 
c 
c 
c 
c 

L 
t 

c 

C 

c 

(.♦♦DIMENSION  ARRAYS 
L 

DIMENSION  IDG <N> . 
DIMENSION  NIVU)  . 
C 

Ct ♦ IN  1 1 IAL12E  NME.NIV 
C 

FP1E-0 
M,,M  >-r» 


KO  -  NUMBER  OF  OPERATOR  INDEPENDENT  VARIABLES  USED  IN 
THIS  MODERATOR  FUNCTION 

NUMBER  OF  ENVIRONMENTAL  INDEPENDENT  VARIABLES  USED  IN 
fHIS  MODERAfOR  FUNCTION 

NUMBER  OF  TASK  INDEPENDENT  VARIABLES  USED  IN 
IMIS  MODERATOR  FUNCTION 

MtO<KO>  -  ELEilENt  NUMBERS  OF  VARIABLES  IN  THE  OPERATOR 
81 ATE  VECTOR 

NEE  <EE>  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  ENVIRONMENT 
STATE  VECTOR 

NlMSKfND  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  TASK  VECTOR 
NME  -  NUMBER  Of  MODERATOR  EQUATIONS 

H!U<1>  -  NUMBER  OF  1NDEPENDEN1  VARIABLES  IN  MODERATOR 
EQUATION  1 

l<!>  -  TIME  DELAY  CALCULATED  FROM  MODERATOR  EQUATION  I 


ide(n:.  dist<3>.  itask(ntsj 

1U>.  XM  <  3) 
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c 

C  ••EVALUATE  «M 

C»«NC  0010  ACRE  FOLKS  10  ,-REDILT  1 1  ME  TO  C0M>UETE  TAEK8  WHICH  REQUIRE 
C«<  COMO  TERM  MEMORY/8YM0OL1C 
WEHMI.I 
HI  V (MME  >ml 
TO*S>»DI>T<I> 

C 

CMCMX  REL1MH  TO  DERIVE  SKILL  MODERATORS  FOR  TIME  TO  COMPLETE 
C 

CALL  RELTMHIDltl  .H1V.MME.T.  KH> 

REIURH 


SUBROUTINE  LMSBPH (IDO,  IDE.  N.  DX«T.  MASK,  NTS,  KM) 


i> 

C 

C< • MODULE l HUMAN  FACTO**  MODERATOR  FUNCTIONS 
Ci •REFERENCE! MOPADS/VOLUME  9.10  OF 
C 

CttPURPCSEiTHIS  SUBROUTINE  RETURNS  PROBABILITY  TO  COMPLETE 
C  LONG-TERM  MEMORY /SYMBOLIC  TASKS 

C 

CM  INMJT  PARAMETERS* 

C  IDO <N)  -  ADDRESSING  INFORMATION  FOR  THE  OPERATOR 

C  XDC (N)  -  ADDRESSING  INFORMATION  FOR  THE  ENVIRONMENT 

C  It  ASK  (NTS)  -  ADDRESSING  INFORMATION  FOR  THE  TASK 

C  N  -  INDEX  FOR  IDO  AND  IDE 

C  NTS  -  INDEX  FOR  I TASK 

C  OUT  (3)  -  NOMINAL  TASK  PARAMETERS 

C  (2)  STANDARD  DEVIATION 

C  (3)  DISTRIBUTION  TYPE 

C 

ctt OUTPUT  PARAMETERS* 

C  XM<1)  -  SKILL  CATEGORY  MODERATOR  VALUES 

C  Xli(l)  -  DIFFERENCE  BETWEEN  DERIVED  AND  BASELINE 

C  MEAN 

C  XH<2)  -  DIFFERENCE  BETWEEN  DERIVED  H ND  BASELINE 

C  STANDARD  DEVIATION 

C  •  XMC3)  •  DERIVED  DISTRIBUTION  TYPE 

C 

Cl  i 

CM  LOCAL  VARIABLES! 

C  KQ  *  NUMBER  OF  OPERATOR  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  Kl  -  NUMBER  OF  ENVIRONMENTAL  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  NT  -  NUMBER  OF  TASK  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  NEO(KO)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  OPERATOR 

C  STATE  VECTOR 

C  NEE(KE)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  ENVIRONMENT 

C  STATE  VECTOR 

C  NT ASK (NT)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  TASK  VECTOR 

C  NME  -  NUMBER  OF  MODERATOR  EQUATIONS 

C  NIV<X)  -  number  of  independent  variables  in  moderator 

C  EQUATION  I 

C  P<I)  -  PROBABILITY- TO-COMPLETE  CALCULATED  FROM  MODERATOR  EQUATION  I 

C 

CMDIMENSION  arrays 

c 

DIMENSION  JDO(N).  XDE(N).  DIST<3).  ITASK(NTS) 

DIMENSION  NEO (2) .  NEE <2> .  NIV<2>,  P<2>.  XH<3> 

DIMENSION  X0<2>.  XE(2) 

C 

CMDEFKtE  NEEDED  ELEMENT  NUMBER9 

r* 
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l*Ml« 

DATA  NEE/4.*/ 

DATA  NIV/2.2/ 

DATA  KJE.KO/2.2/ 

C 

CttTHE  •'ECTOR  ELEMENT*  AM  A9  FOLLOWS* 

C  XOfD-NUHK*  OF  TIMES  Tl*  OPERATOR  MAS  PREVIOUSLY  PERFORMED 
C  THE  TASK 

C  KQ<2>*DAV9  SINCE  THE  TASK  MAS  LAST  PERFORMED 

C  HE  <l>  -NOISE  LEVEL 

C  XE<2>*P40ISE  PREDICTABILITY 

C 

CitF.ITRIEVE  THE  VALUES  FOR  THE  STATE  VECTORS 
C 

CALL  Of T OVA  ( IDO. N. NEC. KO. XO> 

CALL  GCTEVA  < IDE. N. NEE.KE. XE) 

C 

Ct  • INITIALIZE  NME 
C 

NME-O 

C 

Ct •EVALUATE  XM 

CttDATA  FROM  9IE0EL  ET  AL  1*7* 

C 

NME -NME -M 

IF  <  XC  <2> .QT.O.O)  THEN 
C 

CM  NO  I  SC  IS  UNPREDICTABLE 
C 

P (NME) -DIBT <1 ) * < 1 . 01 -0. 002** XE (1 ) ) 

C 

ELSE 

C 

Ct*  NOISE  IS  UNPREDICTABLE 

c 

P (NME > -D I 8T < I ) t (0 . *3-0 . 0043* XE < W ) 

END  IF 
C 

Ct*  DATA  FROM  SIEGEL  1*7* 

C 

C  NOTE*  WE  ASSUME  THAT  IF  THE  HUMAN  MAS  PERFORMED  THE  TASK 
C  CORRECTLY  TEN  TIMES.  HE  19  WELL  TRAINED 

C 

NME -NME ♦ I 

IF  (XOU)  ,GE.  10.0)  THEN 
C 

Ct*  OPERATOR  IS  WELL  TRAINED 
C 

P(NMEJ-DISTU)  t  <.0I6*.3S6<EXP(-.  133*X0<2>>> 

ELSE 

C 

Ct*  OPERATOR  19  POORLY  TRAINED 
C 

P<NME)-0IST(1) * (.069+0. 97*EXP<  . 13tX0<2>  >) 

END  IF 
C 
C 

CttDATA  FPOM  DAVEY ( 1973) 

C 

NME -NME +1 

IF  <  X  T  S'*.  <2>.Lf.2.0>  THEN 

P*N^E>-DIST{I) t (l».0S3t XTSK<2> > 

ELSE 

P ‘NME) -DIST (!)*<!. 03— . 023 * X TSK  < 2 > ) 

ENDIF 

C 
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Cl 

SUBROUTINE  LMSBTHt IDO.  I DC.  N,  DXST,  XTASK.  NT3,  XH) 

C 

C ••MODULE I  HUMAN  FACTORS  MODERATOR  FUNCTIONS 
C« •REFERENCE I MOFAD8/ VOLUME  3.10  DF 
C 

CMPUltPOSEi  THIS  SUBROUTINE  RETURNS  TIME  TO  COMPLETE 
C  TABK9  WHICH  REQUIRE  LONU  TERM  MEMORY /SYMBOLIC 

t* 

If 'INPUT  PARAMETERS! 

C  IDO  <N>  -  ADDRESSING  INFORMATION  FOR  THE  OPERATOR 

C  IDE  IN)  -  ADDRESSING  INFORMATION  FOR  THE  ENVIRONMENT 

C  I TASK < NTS)  -  ADDRESSING  INFORMATION  FOR  THE  TASK 

C  N  -  INDEX  FOR  IDO  AND  IDE 

C  NTS  -  INDEX  FOR  ITASK 

C  DI8T (3)  -  NOMINAL  TASK  PARAMETERS 

C  (1)  MEAN 

C  <2>  STANDARD  DEVIATION 

C  (3)  DISTRIBUTION  TYPE 

C 

CMOUTPUT  PARAMETERS! 

C  XM(I>  -  SKILL  CATEGORY  MODERATOR  VALUE 9 

C  XM(|)  -  DIFFERENCE  BETWEEN  DERIVED  AND  BASELINE 

C  MEAN 

C  XM<2>  «  DIFFERENCE  BETWEEN  DERIVED  AND  BASELINE 

C  STANDARD  DEVIATION 

C  XM (3)  •  DERIVED  DISTRIBUTION  TYPE 

C 

Cl  I 

CMLOCAL  VARIABLES* 

C  KO  -  NUMBER  OF  OPERATOR  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  KE  -  NUMBER  OF  ENVIRONMENTAL  INDEPENDENT  VARIAU.E3  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  NT  -  NUMBER  OF  TASK  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  NEO<KD)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  OPERATOR 

C  STATE  VECTOR 

C  NEElKI)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  ENVIRONMENT 

C  STATE  VECTOR 

C  NTA9K (NT)  -*  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  TASK  VECTOR 

C  NME  -  NUMBER  OF  MODERATOR  EQUATIONS 

C  NJ V < I >  -  NUMBER  OF  INDEPENDENT  VAPTABLES  IN  MOOEPATOR 

C  EQUATION  X 

C  T  < I )  -  TIME  DELAY  CALCULATED  FROM  MODERATOR  EQUATION  X 

C 

Cl ID I MENS I ON  ARRAYS 
C 

DIMENSION  IDO(N).  JD€<N).  0IST(3).  ITASK (NTS) 

DIMENSION  NIV<1).  T<1>.  XH<3) 

C 

CltlNIT IALIZE  NME.NIV 
C 

MME-0 


1/4  *4 


p 

•*'  S* 


k- 

ir; 

V- 

l  • 

>: 

V; 

tJ 

pt 

\s 

V- 

."V 1 

i*  ■ 

?  * 

T- 

S"i 

•V* 

%* 

s 

'.s 

% 

fe 
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c 

c>*rv*LU*T*  m 

chmo  e*»»  ««  roue  m  mcsict  tm  to  owunrt  t<m  wiicm  «hm 
c*i  lm  tw 

M«M*I 

c 

c»*C*ll  r*xrnN  to  OKftlwt  ha1.  KBCMator*  row  tM  to  -swrurtf 

c 

OMX  «U.T>4H<S!*T.M!v.M«.  T.mi 


T 


Cl 


SUBROUTINE  NUMAPH (IDO.  IDE.  N.  DI8T.  I TASK.  NTS.  XM) 


C( (MODULE* HUMAN  FACTORS  MODERATOR  FUNCTIONS 
CttREFERENCEl MOPADB/ VOLUME  S.IO  DF 
C 

C$(PURPOSEl THIS  SUBROUTINE  RETURNS  PROBABILITY  TO  COMPLETE 
C  NUMERICAL  MANIPULATIVE  TASKS 

C 

CtdNPUT  PARAMETERS  I 


C 

c 
c 
C 

c 
c 
c 
c 
c 
c 

Ct (OUTPUT  PARAMETERS! 

C  XMU)  -  SKILL  CATEGORY  MODERATOR  VALUES 


IDO (N)  -  ADDRESSING  INFORMATION  FOR  THE  OPERATOR 
IDE (N)  -  ADDRESSING  INFORMATION  FOR  THE  ENVIRONMENT 
IT  ASK (NTS)  -  ADDRESSING  INFORMATION  FOR  THE  TABK 
N  -  INDEX  FOR  IDO  AND  IDE 
NTS  -  INDEX  FOR  I TASK 
DISK 3)  -  NOMINAL  TASK  PARAMETERS 
(I)  MEAN 

<2)  STANDARD  DEVIATION 
(3)  DISTRIBUTION  TYPE 


C  XM  (1 ) 

C 

C  XM<2> 

C 

C  XM<3> 

C 

CS! 

C((LOCAL  VARIABLES! 


DIFFERENCE  BETWEEN  DERIVED  AND  BASELINE 
MEAN 

DIFFERENCE  BETWEEN  DERIVED  AND  BASELINE 
STANDARD  DEVIATION 
DERIVED  DISTRIBUTION  TYPE 


KE  - 


Nr  - 


C 
C 

c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 

CMDI  MENS  ION  ARRAYS 
C 

DIMENSION  IDO(N). 

DIMENSION  NIV(l) , 
C 

C«*INI TIALIZO  NME.NiV 
C 

MME-A 


KO  -  NUMBER  OF  OPERATOR  INDEPENDENT  VARIABLES  USED  IN 
THIS  MODERATOR  FUNCTION 

NUMBER  OF  ENVIRONMENTAL  INDEPENDENT  VARIABLES  USED  I N 
THIS  MODERATOR  FUNCTION 

NUMBER  OF  TASK  INDEPENDENT  VARIABLES  USED  IN 
THIS  MODERATOR  FUNCTION 

NEO (KO)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  OPERATOR 
STATE  VECTOR 

NlEE(KE)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  ENVIRONMENT 
STATE  VECTOR 

NT ASK (NT)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  TASK  VECTOR 
MME  -  NUMBER  OF  MODERATOR  EOUATIONS 

N1V(I)  -  NUMBER  OF  INDEPENDENT  VARIABLES  IN  MODERATOR 
EQUATION  l 

P(I)  -  PROBABILITY— TO-COMPLETE  CALCULATED  FROM  MODERATOR  EQUATION  I 


IDE (N) .  DIST (3) .  ITASK (NTS) 
P(l>.  XM (3) 
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Ct 

UMVTINS  WLMATNI  ICO.  IOC,  M,  OICT.  itmk,  nts,  tn» 

CltKBUJiiHUWN  PACTOP*  WWkTW  rUNCTICM 

ct«mp*RS>c«i  norms' <*aujMt  a.  *o  or 

c 

cirnroKiTHii  mwcittix  wnMi  Tim  ro  conputte 

C  TMKI  WHICH  ACOUIPC  NUMCJUC  MANIPULATION 

c 

C«ll»rUT  NMMf'INi 

C  I00«NI  -  ADDRESS I NB  INFORMATION  row  TWR  OPERATOR 

C  IOC  INI  -  AOOMCSBIMB  INFORMATION  PQA  THf  CNVlNCH NtNT 

C  ITASKINT*)  -  AODA4BBJN0  INFORMATION  POM  THE  TANK 

C  N  -  I  NOVI  PON  COO  **0  IOC 

C  NT*  -  1M0CX  POM  STACK 

C  OICT (3)  -  NOMINAL  T«*k  RAPAfSITERS 

C  41)  ME  AM 

C  <21  STahLAPD  OCV|AT;ON 

C  «3>  DISTRIBUTION  TVPC 

c 

C* •OUTPUT  PMNCTmi 

C  XM<I>  -  *K ILL  CAT COOP V  MODERATOR  VALUES 

C  XM<J)  -  DIFFERENCE  BETWEEN  OCftlVCD  AND  BASELINE 

C  NCMi 

C  *H<2)  •  DIFFERENCE  BCTWCCN  DCPXVCO  ANO  BALCLINE 

C  CTANOAAO  DEVIATION 

C  XM<3>  •  DERIVED  PC BTP I BUT CON  TVP* 

C 

C»I 

CMLOCAL  VARIABLES! 

C  FO  -  NUMBER  OP  OPERATOR  INOCPCNDCNT  VARIABLES  UBCP  IN 

C  THIS  MODERATOR  FUNCTION 

C  K£  -  NUMBER  OP  ENVIRONMENTAL  XNPCPCNOCNT  VAP TABLES  USED  IN 

C  THIS  NO OCR A TOP  FUNCTION 

C  NT  -  NUMBER  OP  TASK  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  NEO <K0>  -  CLEMENT  NUMBERS  OP  VARIABLE*  IN  THE  OPERATOR 

C  STATE  VECTOR 

C  NET < PE)  -  CLEMENT  NUMBER*  OP  VARIABLES  IN  THE  ENVIRONMENT 

C  STATE  VECTOR 

C  N TASK (NT)  -  ELEMENT  NUMBERS  OP  VARIABLES  IN  THE  TASK  VECTOR 

C  NME  -  NUMBER  OP  MODERATOR  EQUATIONS 

C  NIVClS  -  NUMBER  OP  INDEPENDENT  VARIABLES  IN  MODERATOR 

C  EQUATION  I 

C  T  < I )  -  TIME  DELAY  CALCULATED  PROM  MODERATOR  EQUATION  I 

C 

CMDIMENSIQN  ARRAYS 
C 

DIMENSION  IDO<N;.  I DE  ( N )  .  DIs»T<3>.  ITASK<NTB> 

DIMENSION  NEO (2) .  NEE ( I > .  NIV<2).  T<2>.  XM<3) 

DIMENSION  XE  (  I )  .  X0<2) 

C 

C* •DEFINE  THE  LENGTH  OP  STATE  VECTORS 
C 


t 


*  % 

\  ly 


'  •-  rv 


c 

ct 

c 


■ai* 

SMC  CUtHEWT 


■At*  NKX/4/ 
■At*  NT3/4.1/ 


CtttHt  **c*.rm  tLMNTt  am  *■  fXiMt 

c  (1iip*«;«  k.j:v«L 

C  OP  C*/tv 

C  SO<2t*f|i«  C*  TAW 
C 

c 

CJPftKTRItvt  vACUCt  PC*  rx  ttAt*  vectors 

c 

Cacl  Mtiv*(lM.M««<t.rr.xti 

CMX  SCTCMtlOO.M.NCa.M).  *£> 

c 

CMINIttALJrC  MX.MtV 

c 

M*0 

MIV«|>«2 

*IV<2>-| 

N|V(3l«| 

C 

C ••EVALUATE  AH 

c 

c 

CtPDATA  PR»1  SIEGEL  ft  At.  |97* 

c 

»<■»<♦  1 

TD»Tlr«(0) 

IF  (TD.OC.IOOO)  THD- 
TD-I’D-IOOO) MOO 

ELSE 

rD-<TDM<00>  MOO 
t*DIP 

T  (l*K)«DllTa>l(1.0*  123.43/ C  <TDt  ( I.  *9-.  0*91  X0<  t)  >>♦ 

♦  <T0M21<-.C?*.OO3tXOU>  M*<l2C.9-.OOe31XQ<  W  >  > > 

c 

c 

CMFROT  MCURMICK  i*XACT  RELATIONSHIPS  ARE  HYPOTHESIZED) 

c 

N.«-NME>i 

IF  <XE<1> .ST. 00,0)  THEN 

T (NMEJ *D1ST <  1 )  t2.0M  <  ( X£  <  1 )  -00)  /30.0) 

ELSE 

T(NME)-DIST(1> 

ENDIF 

C 

CttHYPOTHESIZED  RELAT I ONSH I P-LAUGHER Y , l9tJ 
NME-NME-M 

IF  <X0 (2) . LT.0.O)  THEN 
T<NME)»DIST<1> 

ELSE 

T  <NME  > "D  1ST (l)*<<XO(iJ“S.O) t0.05+l.0> 

END  IF 
C 

COCALL  FELTMH  TO  DERIVE  SKILL  MODERATORS  FOR  TIME  TO  COMPLETE 
C 

CALL  RELTMH<DIST.N1V.NME. V.XM) 

RETURN 

END 
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tUB*OUT!Nf  NllNitW.  lOt.  N.  OUT ,  I  TASK. 

C»  •MODULE  I  HUMAN  WHClOfi*  «OWW*TW  FUNCTIONS 

ctvmtrtwctifi^AM/voiuHi  3.10  or 

c 

CMPUfmil  this  SUSROUTIHt  RETURNS  PROBABILITY  TO  OOM«lXTt 
c  PROBABILITY  ESTIMATION  TASKS 

c 

CttlNTUT  RRRA*«TtRS» 

c  loo (N>  .  adore  Mine  iNFO^mrioK  for  thc  operator 

C  IDE  <M1  -  ADDAS  SI  I  HQ  IPP'ORMATJON  FOR  THt  ENV  I  ROMMENT 

C  1  I  ASK  (NTS)  -  aODACSBINS  INFORMATION  FOR  7 MS  TASK 

C  M  -  1NDSX  FOB  IDO  AMO  IDS 

C  NTS  -  I  HOC*  FOR  | TASK 

C  OJSr  <  3>  -  NOMINAL  TASK  PARAMETER* 

C  < I >  MEAN 

C  <2>  STAWOAPO  DEVIATION 

c  •  <3i  distribution  type 

c 

C**OUTPtJT  PARAMETERS* 

C  XHClJ  -  SKILL  CATE30RY  HODEfcATOR  VALUES 

C  XM < 1 >  •  DIFFERENCE  BETWEEN  DERIVED  ANO  BASELINE 

C  MEAN 

C  XM<2>  •  DIFFERENCE  BETWEEN  DERIVED  AND  BASELINE 

C  STANDARD  DEVIATION 

C  XM<3>  •  DERIVED  DISTRIBUTION  TYRE 

C 

Cl  l 

C ••LOCAL  VhRIABLESi 

c 


►.0  -  NUMBER  OF  OPERATOR  INDEPENDENT  VARIABLES  USED  IN 
THIS  MODERATOR  FUNCTION 

KE  -  NUMBER  OF  ENVIRONMENTAL  INDEPENDENT  VARIABLES  USED  IN 
THIS  MODERATOR  FUNCTION 

NT  -  NUMBER  OF  TASK  INDEPENDENT  VARIABLES  USEE  IN 
THIS  MODERATOR  FUNCTION 

NEQ<KO>  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  OPERATOR 
STATE  ‘/ECTOR 

NEE <KE>  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  ENVIRONMENT 
STATE  VECTOR 

NIASKCNT)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  TASK  VECTOR 

NME  -  NUMBER  OF  MODERATOR  E0UATI0N8 

NIV(I)  -  NUMBER  OF  INDEPENDENT  VARIABLES  IN  MODERATOR 
EQUATION  I 

R<I >  -  PRODAB  I wITY-TO-COMPLETE  CALCULATED  FROM  MODERATOR  EQUATION  I 


C 

c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 

CTf DIMENSION  ARRAYS 

c 

DIMENSION  IDO  <N> .  IDE  <N) .  DIST<3>.  ITA8K<NT3> 
DIMENSION  NI V ( 1 > •  P(|).  XMC3) 

c 

C*TINI  T  IAL22E  NHE.NIV 
C 

NME-0 
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c 

CttCvMUJATt  JR 

C««NO  ORTA  MtRC  ROUNO  TO  FACfilCT  RRQ0ARIL I TV-TO-CORRL*T«  RROMUtlTV 

ctt  bstiratictj  Tmu 
c 

NIV<NMK>»| 

c 

cmcjcl  ro  o**ivt  will  roocaatoa*  for  froravilitv-to*corrlctc 

c 

CALL  ftftLF**4<0!tT.NSV.tM>.XR> 

RKTURM 


—  V 


SUBROUTINE  PAESTHUDO.  I  DC.  N,  DX8T.  STACK,  MTS.  XfM 

c 

etanOOULC'HlJVWN  FACTORS  MODERATOR  FUNCTIONS 
CaaREFEACNCEiMOPADS/VOLURE  9.10  0* 

c 

caaruRPOsci  this  subrouti*^:  returns  time  to  complete 
C  TACKS  WHICH  REQUIRE  PROBABILITY  ESTIMATION 

c 

Cat  INPUT  PARAMETERS* 

C  IDO  (N)  -  ADDAESBIN3  INFORMATION  FOR  THE  OPERATOR 

C  IDE  (NT  -  ADDRESS  I  NO  INFORMATION  FOR  THE  ENVIRONMENT 

C  I  TASK  (NTS)  -  ADDRESS  I  NO  INFORMATION  FOR  THE  TASK 

C  N  -  INDEX  FOR  IDO  AND  IDE 

C  NTS  -  INDEX  FOR  I  TASK 

C  01 ST (3)  -  NOMINAL  task  PARAMETERS 

C  Cl)  MEAN 

C  C2)  STANDARD  DEVIATION 

C  <3)  DISTRIBUTION  TYPE 

C 

CttOUTPUT  PARAMETERS* 

C  M1<I>  -  SKILL  CATEGORY  MODERATOR  VALUES 


C  XMU)  -  DIFFERENCE  BETWEEN  DERIVED  AND  BASELINE 

C  MEAN 

C  XH<2>  -  DIFFERENCE  BETWEEN  DERIVED  AND  BASELINE 

C  STANDARD  DEVIATION 

C  XHC3)  •  DERIVED  DISTRIBUTION  TYPE 

C 

C»  l 

CtaLOCAL  VARIABLES*  ! 

C  KO  -  NUMBER  OF  OPERATOR  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  KC  -  NUMBER  OF  ENVIRONMENTAL  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  NT  -  NUMBER  OF  TASK  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  NEO (KO)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  OPERATOR 

C  STATE  VECTOR 

C  HEE(KE)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  ENVIRON ME  I  IT 

C  STATE  VECTOR 

C  NTASK(NT)  -  ELEMENT  NUMBERS  OF  VARIABLES  XN  THE  TASK  VECTOR 

C  NME  -  NUMBER  OF  MODERATOR  EQUATIONS 

C  NIVtl)  -  NUMBER  OF  INDEPENDENT  VARIABLES  IN  MODERATOR 

C  EQUATION  l 

C  MI)  -  TIME  DELAY  CALCULATED  FROM  MODERATOR  EQUATION  I 


CtaOIHENSION  APRAY9 
C 

DIMENSION  I  DO (N) , 
DIMENSION  NIV(l) . 
C 

CaaiNI T IALI ZE  NME.NIV 
C 

hme»o 


IDE (N) .  DIST (3) •  ITA8K (NTS) 
TUI,  XM(3) 


S' 


VfSWTTff?} me  V?&1 r.  i*ar  jjr  jgrvygjnCTtrtm  » »  mm  m 


MiVtl»*V 

c 

CT*«valuat«  in 

CtHC  DATA  MM  rOUNO  TO  AACOICT  TIAC  TO  COMPUTTI  TASKS  KM  I OM  ACQUIS* 
CM  PAOSASILITT  1ST 1 HAT  ION 

mm  nt»i 

M|V«NHK>»t 

rtlM>»OllT<|> 

c 

CttCAU..  AIL  TAM  TO  OCA  I  Vf  SKILL  HOOCAATOAS  AOA  Tine  to  corcn-rrc 

c 

Call  acltmm<dist„hiv.ia*.t.*h> 

ACTUNM 

CMC 


*  * 

Ik 
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’WEmstosr. *: riT;.y;r,"v:r.  ty *Rrfr»rrerrjrz ryy: »■,  c> >rt»k«’g« ;  «vfxf? 


Ci 

SUBROUTINE  RCACPHl  IDO,  IOC.  M.  BIST,  'TASK.  MTS,  XH> 

C 

C* (MODULE i HUMAN  * AC TOW*  MODERATOR  FUNCTION! 

c»fwerEwtHCfci nowwoi/voLUMC  s. 10  of 

c 

CttWUWWOSCi  THIS  SUBROUTINE  RETURNS  WOBfll I L I T V - TD-COMPLE TE  MODERATORS 
C  FOR  AUDITORY  AND /OR  VISUAL  REACTION  TIME  TASK! 

C 

C* • INPUT  PmAAMCTFAS* 

C  I  DO <  N  >  -  ADDRESSING  INFORMATION  FOR  THE  OPERATOR 

C  IDE  <N)  -  ADDRESSING  INFORMATION  FOR  THE  ENVIRONMENT 

C  1TA8»(NTS>  -  ADDRESSING  INFORMATION  FOR  THE  TASK 

C  N  -  INDEX  FOR  IDO  AND  IDE 

C  NIS  -  INDEX  FOR  ITASK 

C  DI ST  <  3)  -  NOMINAL  TASK  PARAMETERS 

C  11)  MEAN 

C  C2>  STANDARD  DEVIATION 

C  <  3)  DISTRIBUTION  TYPE 

c 

C ••OUTPUT  PARAMETERS* 

C  HUM)  -  SKILL  CATEGORY  MODERATOR  values 

C  XMU)  •  DIFFERENCE  BETWEEN  DERIVED  AND  BASELINE 

C  MEAN 

L  XM<2>  -  DIFFERENCE  BETWEEN  DERIVED  AND  BASELINE 

C  STANDARD  DEVIATION 

C  XM < 3)  •  DERIVED  DISTRIBUTION  TYPE 

C 

Cat 

CMLOfAL  V*WIA3LES* 

C  KO  -  NUMBER  OF  OPERATOR  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  KE  -  NUMBER  OF  ENVIRONMENTAL  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  NT  -  NUMBER  OF  TASK  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  NEO <KU)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  OPERATOR 

C  STATE  VECTOR 

C  NEE  <KE)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  ENVIRONMENT 

C  STATE  vrCTOR 

C  NTASKtNT)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  TASK  VECTOR 

C  NME  '  NUMBER  OF  MODERATOR  EQUATIONS 

C  ,  HIVU)  -  NUMBER  OF  INDEPENDENT  VARIABLES  IN  MODERATOR 

C  EQUATION  I 

C  P(l)  -  PROBABILITY  TO  complete  CALCULATED  FROM  MODERATOR 

C  EQUATION  1 

c 

C ••DIMENSION  mPRAYS 

c 

DIMENSION  JDO<N).  IDE(N>.  DIS1<3).  ITASK (NTS) •  XM<3> 

DIMENSION  NIV(l).  P(I) 

c 

CMIMST1ALIZE  NME.NIV 
C 


R-61 


NMt-O 

NIVfl  >•!> 

c 

CMfVALUATl  IN 

CMfHBR*  MKRC  NO  DATA  DCSCRIBING  ABACTION  TIN*  PAO*\LlTIC« 

C 

HH*«NN*»I 

NlV<NM*>-t 

R<I**)-D1STCI> 

C 

C  •  tCS*U-  RCLRNM  TO  DBA  JVC  CK  ILL  MODERATORS  FOR  REACTION  TIM*  TASKS 
C 

CALL  R*J-RNM(DI1T.NIV.NN*.R.  *N> 

1++  ACT URN 
KND 


R-t  _ 


AA  '  ,>A 


%'s 


v:/.vv  '^  v.v/j 


-;.V.V  .V.V.’.V  -'.V'o.VT. - 


SUBROUTINE  RCACTHUDO.  IOC,  N,  DXtT,  IT  ASK,  NTS,  XM> 

c  • 

Ct • MODULE l HUMAN  FACTORS  MODERATOR  FUNCTIONS 
Ct •REFERENCE! MORAOB/VOLUrie  3.10  OF 
C 

C**PUPPOS£i THIS  SUBROUTINE  RETURNS  TIME-TO-CCHPLETE  MODERATORS 
C  FOR  AUDITORY  AND/OR  VI BUM.  REACTION  TIME  TASKS 

C 

CM  INPUT  PARAMETERS* 

C  IDO<N>  -  ADDRESS  I NO  INFORMATION  FOR  THE  OPERATOR 

C  IDC(N)  -  ADDRESSING  INFORMATION  FOR  THE  ENVIRONMENT 

C  ITASK (NTS)  -  ADDRESSING  INFORMATION  FOR  THE  TASK 

C  N  -  INDEX  FOR  IDO  AND  IDE 

C  NTS  -  INDEX  FOR  ITASK 

C  D 1 5T  < 3 )  -  NOMINAL  TASK  PARAMETERS 

C  (1)  MEAN 

C  <2 J  STANDARD  DEVIATION 

C  <3)  DISTRIBUTION  TYPE 


CMOUTPUT  PARAMETERS* 

C  XMU)  -  SKILL  CATEGORY  MODERATOR  VALUE 3 


C 

C 

c 

c 

c 

c 

Cit 

CMLOCAL 

c 

c 

c 


DIFFERENCE  BETWEEN  DERIVED  AND  BASELINE 
MEAN 

DIFFERENCE  BETWEEN  DERIVED  AND  BASELINE 
STANDARD  DEVIATION 
DERIVED  DISTRIBUTION  TYPE 


kO  -  NUMBER  OF  OPERATOR  INDEPENDENT  VARIABLES  USED  IN 
THIS  MODERATOR  FUNCTION 

KE  -  NUMBER  OF  ENVIRONMENTAL  INDEPENDENT  VARIABLES  USED  IN 
THIS  MODERATOR  FUNCTION 

NT  -  NUMBER  OF  TASK  INDEPENDENT  VARIABLES  USED  IN 
THIS  MODERATOR  FUNCTION 

N€0<K0>  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  OPERATOR 
STATE  VECTOR 

NEE (KE)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  ENVIRONMENT 

state  vector 

NTASK(NT)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  TASK  VECTOR 
NME  -  NUMBER  OF  MODERATOR  EQUATIONS 

NIV(I)  -  NUMBER  OF  INDEPENDENT  VARIABLES  IN  MODERATOR 
EQUATION  I 

T  C I >  -  TIME  TO  COMPLETE  CALCULATED  FROM  MODERATOR 
EQUATION  X 


Ct •DIMENSION  ARRAYS 
C 

DIMENSION  I  DO (N> •  IDE (N> .  DIST<3>.  ITA5K<NTS> 

DIMENSION  NEE (1) .  NED  <4) .  NTSK(6>.  NJV(9>,  T<9>.  XM<3> 
DIMENSION  XE ( 1 ) .  XQ (4 ) ,  XTSK<6) 

C 

Ct •define  length  or  ENVIRONMENTAL,  operator,  and  task  STATE  VECTORS 


c 

DATA  KI/!/ 

DATA  KO/4/ 

DATA  NT/*/ 

C 

Ct (DEFINE  NEEDED  ELEMENT  NUMBERS 
C 

DATA  NEE/7/ 

DATA  NEO/ 12. 58.34.22/ 

DATA  NT5K/3. 10. 7. 8. 3. 4/ 

C 

Ct (DEFINE  THE  VECTOR  ELEMENTS 
C  XEU> •VIBRATION  IN  HI 
C  XQ( 1 >—TARG6T  TYPE 
C  XO (2 > -OPERATOR  EXPERIENCE 
C  XO  <3> -SIGNAL  PROBABILITY 

C  XO <4 > •SIGNALS  PER  MINUTE  * 

C  XTSK(l)»YABK  MODALITY 

C  XTSK  (2>  —NUMBER  OF  ALTERNATIVE  RESPONSES 
C  XTSK (3) -DISTANCE  TO  SNITCH/KEY  IN  FEET 
C  XTSK  (4) •WIDTH  OF  3WITCH/KEY  IN  FEET 
C  XTSK  (/,» -RESPONSE  MODE 
C  XTSK (A) -NUMBER  OF  DI9PLAY3  MONITORED 
C 

C( (RETRIEVE  VALUES  FOR  OPERATOR  AND  TASK  STATE  VECTORS 
C 

CALL  CETEVA  (IDE.  N.  NEE.  I Z.  XO 
CALL  OETOVA  (IDO.  N.  NEO.  KO.  XO) 

C 

CitNTSK  CONTAINS  ELEMENT  NUMBERS  OF  THE  TASK  SPECIFIC  HUMAN  FACTORf  DATA 
C 

ICPT-1 

CALL  GETT3A  (IOPT.XTASK.  NTS.  NTSK.  NT,  XTSK) 

C 

C(«INITIALXIE  NME.NIV 
C 

NME—O 

NlVU>-0 

C 

C( (EVALUATE  XM 

C( ( XTSK ( 1 ) —TASK  MODALITY 

c 

IF  (XTSK (I) . EQ. 1.0) GO  TO  I 
IF  (XTSK ( 1 ) .EQ. 10.0)03  TO  2 
IF  (XTSKU)  .EQ.  11.0)60  TO  3 
C 

CM  THE  TARGET  IS  AUDI  TORY 
C 

1  NHL-NME+I 
NIV(NME>-; 

T (NME) —DIST ( 1 ) 

C 

COCALL  RELTHH  TO  DERIVE  SKILL  MODERATORS  FOR 
C  AUDITORY  REACTION-TIME  TASKS 
C 

CALL  RELTHH (DIST.NIV. NME. T. XM) 

GO  TO  999 
C 

C(( THE  TAPCjCT  IS  VISUAL 

CM  XTSK  (2) -NUMBER  OF  ALTERNATIVE  RESPONSES 
C 

2  IF  < XTSK (2) .EO. I) THEN 
C 

CMTMIS  15  A  SIMPLE.  VISUAL.  REACTION-TIME  TASK 
C«»XTSK (3) -DISTANCE  TO  SWlTCH/KEY  IN  FEET 
CftX INCHP-O I  STANCE  TO  9WITCH/KEY  IN  INCHES 
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H*XlWKt4>-WiUlH  UP  bWilLH/KE*  IN  Fttl 
CttXINCHW-WIDTH  OF  SWITCH/KEY  IN  INCHES 
CttXID-INDEX  OF  DIFFICULTY 

CttDATA  FROM  FI TT8  AND  PETERSON.  1964,  PAGE  110 
C 

NME-NME+1 
NlV(NHE>-2 
XINCHD-XT9K<3) /12.0 
XJNCMW-XTBK  (  *>/I2.0 

X ID— ( ALQG ( <2tXlNCHD' /XINCHW) > /O. 693 
T (NME)»< <74. OtX ID) -37.0) / 1000.0 

C 

CttDATA  FROM  FITTS  AND  PETERSON.  1964,  PAGE  107 
C 

NME-NMEM 
NIV (NttE) —2 

T  <NME)  •  <261  •  0*  (S.  4t  XID) )  / 1000.  O 
C 

CMC  ALL  ABB  rMH  TO  DERIVE  SKILL  MODERATORS  FOR 
C  8IMPLE.  VISUAL.  REACTION-TIME  TASKS 
C 

CALL  AB8TMH (D IBT.NIV. NhC. T.  XH) 

GO  TO  999 
ENDIF 
C 

CttTHI?  IS  A  CHOICE.  VISUAL.  REACTION-TIME  TASK 
Ct*XTSK(S)-PC9P0NSE  MODE 
C 

IF  <XrSK(3).E0. 10.0) THEN 
C 

CttTASK  REQUIRES  A  VOICE  RESPONSE 
CtftXOU* -target  type 
c 

IF  (XO(l) .EQ.36.0)THEN 
C 

CttTASK  REQUIRES  VOICE  RESPONSE  TO  A  LIGHT 
CttDATA  FROM  TCICMNER  AND  KHEB3.  1974,  PAGE  01 
C 

NME-NME+l 
NIV  <NME>  —3 

T  <NME>  -  (0.  43B+0.  034t XT9K  (2)  )  /60.  0 
C 

CttCALL  ABSTMH  TO  DERIVE  SKILL  MODERATORS  FOR  CHOICE.  VISUAL. 

C  REACTION-TIME  TASKS  WHICH  REQUIRE  A  VOICE  RESPONSE  TO  A  LIOHT 
C 

CALL  ABSTMH <DXST. NIV. NME. T. XM) 

GO  TO  999 
ENDIF 

IF  (X0<1) .EO. 37.0) THEN 
C 

CttTASK  REOUIPES  VOICE  RESPONSE  TO  A  DIGIT 
C 

NME-NME+1 
NIV  <NME  >  —3 

T (NME) —  <0. 419+0. COcOl tEXP  < 1 . 331 1 XTSK 12) ) //60.0 
C 

CttCALL  ADS T KM  TO  DERIVE  SKILL  MODERATORS  FOR  CHOICE.  VISUAL. 

C  REACTION-TIME  TASKS  WHICH  REQUIRE  A  VOICE  RESPONSE  TO  A  DIGIT 
C 

CALL  ABSTMH  <DI  ST .  NIV.  NME.  T.  Xri) 

GO  TC  999 
ENDIF 
C 

CttTASK  REQUIRES  A  VOICE  RESPONSE  TO  A  NON-LIGHT.  NON-DIGIT  STIMULUS 
C 

NME -NME -M 


ik* 


g 


v> 

h 
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M 

h 


V. 

£  £ 


r.\  *-% 

fc«*  amt 

p^8 


St' 


It  i 


c%  •' 

t-s. 


niv<nme>-i 

t<nme>~oibtu> 

c 

CttCALL  MD.TW  Tft  DERIVE  «K2LL  MODERATOR!  TQM  CHOICE,  VI8UAL. 
C  REACTION-TIME  TMXI  WHICH  REQUIRE  A  VOICE  REBROKW  TO  A 
C  N0N-LI8HT.  NON-DIBIT  BTINULUB 
C 

CALL  RELTHH(DIBT.NIV,M*.T.XH> 

80  TO  777 


Cl.TABK  KEOUIAES  A  MANUAL  AEBRON1E 
C 

IF  <XO(1).B0.8A.O>THEM 
C 

CMTASK  REQUIRE!  A  MANUAL  REBFQHMt  TO  A  LIBHT 
C 

H»HE«i 

HIV(W*>-3 

T<NME>-<0.AOA-0.A*9«EXF(-O.3O7tXT!K<2>>>/AO.O 

INDIA 

IF  <X0(I>.BQ.S7.0>THEN 

c 

COTAS*  REQUIRE!  A  MANUAL  RESFON8E  TC  A  DIBIT 
C 

MIVIWTZ:  >3 

T  <NHE)  •  (O.  308*0.  047. XT!* 12)  >  /AO.  O 

c 

CM*E<l>*VIBAVriOH  IN  HZ 

C..DATA  FRC.1  NOLMTAT.  BITTNER,  AND  8UI8NAR0.  1782 

c 

NNE-M«*» 

MIV<HHE>»« 

T ( NHC > •  < 1 . 800-0 .  1 A7 .  XC (I , *0 . 004 * X E (1  >  « « 2 )  / AO . O 

CMC  IF 
8N0JF 
C 

C**OATA  FROM  8IE0EL.  FFEIFFER.  KORBTT.IM.  HILBON.  AM)  OZPCARTAN,  1777. 
b 

HMt«NME*l 
HX  V  (NHC  )  ■  X 

T (NHC>- <0.720-0. 781 15XP  <-0. 23*»  XTlK (2) ) >/60.0 
C 

C11X0<2>«K)P€PAT0P  CXPCPIENCC 
CHX0<3?*S10NAL  PROBABILITY 

CMDATA  PPOH  TC1»#«P  AND  KPCBC.  1*74.  PA0C  C7 
C 

NHC -NHC- 1 

niv<nhC>-2 

T(Nh£)-<0.4<n-0.PQ0041X0(2)-0. 1671X0 (3) > /60. 0 

c 

CMDATA  P*OM  TtICMMCP  AND  KNEW,  1*74.  PACK  0* 

c 

NHC -NHC* 1 
NIV  (NHC )  —1 

T  (NHC)  •  <0.  4l*-0.  1179X0(3)  >/6O,0 

c 

CMDATA  ntOH  TIICHNCP  AND  KNEW.  1*74.  PACK  «2 
C 

NHC— NHC* 1 
NXV(NHC) — 2 

X2»ALCW(XTS*t2>  >  /0.4*3 

A-O. 4231 X*?*0. 2*3 

Xfc—-0. 071AL5Q1 0 ( XT3K (2) ) -0.02* 

T <NHE> •  (  XKtALOO  10  <  XO <2>  >  -A)  '60.0 


cttOAia  ran  texo+xa  and  kaess,  1*74,  paof  u 
c 

nhk-nme«-s 

NIV(NME>-2 

A-0.  170*X2>0. 140 

XK— 0.0171X2-0.001 

T  < NW )  •  <  X K I  ALO0 1 0  <  X 0 < 2 )  «*>  >  / *0 . 0 

c 

cttoATA  ran  texchnea  and  kaess,  1*74.  pass  aj 

c 

N!V<NME>-2 

T <NMB> «<0. 404+0. OlOtXTSK  (2)  -o. 0000001  txo U>  > /40. 0 

c 

CMX0<4> -SIGNALS  PCA  MINUTE 

Ct»XTSK(A)-NUrieCP  OF  DISPLAYS  MON 1 TOWED 

CttDATA  FAOM  0OLDSTEXN  AND  DUATNAN.  1T7S,  PAGE  404 

C 

111  !•«♦! 

NIV(MHE>«2 

T  (NME >  - ( -O. 04 1 *0.  ©01  »X0 «4)  ♦O. 0741XTSK  (4)  )  /AO. 0 
C 

C It CALL  AMTMH  TO  DEAXVC  SKILL  MQDEAATOA*  FOA 
C  FOA  CHOICE.  VISUAL.  AEACT ICN-TIME  TASKS 
C 

CALL  ASSTMHIDIST ■ NX V, NME. T • XH> 

00  TO  T77 

,  c 

CftTHIS  IS  A  AEDUNDANT.  VISUAL  AND  AUOXTOAY  AEACTION-TIME  TASK 

c 

3  HHE-NMEM 

HI V (NME >  —  1 

T(NMC)-DI8T(1> 

C 

C««CALL  P€LTMH  TO  DCPIVE  SKILL  MQDCAATOA*  FOA  ASDUNOANT  VISUAL 
C  AND  AUDITORY.  REACT ION-T IMf  TASKS 
C 

CALL  PEL  TIIH  (DIET •  NX V. NME. T •  XN> 

TfS  PI TUAN 

END 


Cl 


HMUTI«  ACCOPHUDO. 


toe. 


M. 


DIET. 


ITASK, 


c 

ClimmiHUNM  FACTORS  MODERATOR  RUCTIONS 
C»  •REFERENCE  l  HOARDS /VOLUT*  a.  10  OF 


NTS . 


XH> 


c 

C»YP(JAPt>S*l  THIS  SUBROUTINE  RETURNS  PROBAOILITY-TO-AtCOBNlZE  HOCXRATUA* 
C  FOR  AUDITORY  AMO /OR  VISUAL  RSCOBNITION  TASKS 

c 

csstiruT  parameter*! 

C  IDO  INI  -  ADDRCMINS  INFORMATION  FOR  THE  OPERATOR 

C  IOC  (HI  -  ADDRESS  IMS  INFORMATION  FOR  THE  ENVIRONMENT 

C  I  TASK  (NTS)  -  ADDRESS  I NQ  INFORMATION  FOR  THE  TASK 

C  N  -  INDEX  FOR  100  AND  IOC 

C  MTS  -  INDEX  FOR  I TASK 

C  DIET (3)  -  NOMINAL  TASK  PARAMETERS 

C  til  YEAN 

C  (3)  STANDARD  DEVIATION 

C  <31  DISTRIBUTION  TYPE 

C 

CSSOUTPUT  PARAlVTERSl 

C  XN<I»  -  SKILL  CATSaORV  MODERATOR  VALUES 

C  XR<U  «  DIFFERENCE  SETmCEN  DERIVED  AND  BASELINE 

C  fVAM 

C  XNCJ)  •  DIFFERENCE  BETWEEN  DERIVED  AND  BASELINE 

C  STANDARD  OBVIATION 

C  XH<3I  »  DERIVED  DIDTRIDUTION  TYPE 

C 


Cll 

C« 'LOCAL  VARIABLES I 

C  KO  -  NUMBER  OF  OFERATOR  IH0CPE1CENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  KE  -  NUMBER  OF  ENVIRONMENTAL  INDEPENDENT  VARIABLES  UBEO  IN 

C  THIS  MODERATOR  FUNCTION 

C  NT  -  NUBIX  OF  TASK  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  NEO (KO)  -  ELEMENT  NUMBERS  OF  YARD  BLEB  IN  THE  OPERATOR 

C  STl.IC  VECTOR 

C  NEE  (KE)  •  ELEMENT  tAJMDCRS  OF  VARIABLES  IN  THE  ENVIRONMENT 

C  BTATE  VECTOR 

C  NT  ASK  (NT)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  TASK  VECTOR 

C  NWB  -  NUMBER  OF  MODERATOR  EQUATIONS 

C  HIV(I)  -  NUMBER  OF  INDEPENDENT  VARIABLES  IN  MODERATOR 

C  EQUATION  I 

C  F < I )  -  PROBABILITY  TO  COMPLETE  CALCULATED  FROM  MODERATOR 

C  EQUATION  I 

C  1 

CUD  I  MENS  I  CM  ARRAYS 

c 

DIMENSION  IDO (N) ,  IOC (N)  ,  DISTI3).  I  TASK (NTS) 

DIMENSION  NEE ( I ) •  NEO (10).  NTSfcC).  NIV(3).  P(3>,  XC(I).  XM(3) 
DIMENSION  10(10).  XTSK  (2) 

c 


rtlAEFO*  (EMCTH  OF  CT» '  1  FOMENT  A*. .  CAEARTOP.  AND  TASK  STATE  VECTORS 


DATA  KC/I/ 
OATH  ICO/  10/ 
DATA  NT/2/ 


Ct* DEFINE  HERDED  ELEMENT  NUMBERS 
C 

DATA  ICI/4/ 

DATA  NE0/S4.57.37.3G.34.  17.40.12.14.43/ 

DATA  NTSK/3.4/ 

C 

CttOCFlNC  THt  VECTOR  ELEMENTS 
C  XEU)-A«SICNT  NOISE  LEVEL  IN  OB 
C  X0(1)-T  ANGST  NOISE  LEVEL  IN  DB 
r.  XO <2) •TAAOCT  DURATION  IN  MXNUTKB 
C  X0<3)*TARO£T  height  IN  Ftr 
C  XO  (4)  —TARGET  WIDTH  IN  FEET 
C  X0(3) •TARGET  DEPTH  IN  FEET 

C  *0(4) •SLANT  RANGE  TO  TARGET  IN  NAUTICAL  NILES 
C  XO  (7 )  -HORIZON!**.  RANGE  TO  TARGET  IN  NAUTICAL  NILES 
C  X0<  8)  -TARGET  TYPE 
C  XO (4 > -BINOCULAR  USAGE 

C  XOCIO) •OBSERVER  OFFSET  IN  NAUTICAL  NILES 
C  XTSK  < 1 >—TA9K  MODALITY 

C  XTSK  <2) -THE  OBSERVER -TO -TARGET  POSITION 
C 

C« •RETRIEVE  VALOIS  FOR  OPERATOR  AND  TASK  STATE  VECTORS 
C 

CALL  6CTEVA  (IDE.  N.  NEE.  KE.  XE) 

CALL  BET OVA  (IDO.  N.  ICO.  KO.  XO) 

c 

CttNTBK  CONTAINS  ELEMENT  NUMBERS  OF  THE  TASK  SPECIFIC  HUMAN  FACTORS  DATA 
C 

IOPT—1 

CAU.  OETTSA  (IOPT.ITA0K.  NTS.  NTSK.  NT.  XTSK) 

C««!NIT1Ai!Z£  HMK.NI V 
C 

NME-O 
NXV 1 1 ) —O 

c 

Ct •EVALUATE  XH 
C*4XTSKU)-TASK  MODALITY 
C 

IF  (XTSKU).EO.  1.0)30  TO  1 
IF  (XTSK (l).EO. 10.0)00  TO  2 
IF  (XTSK(l) .EO. 11.0)00  TO  IP 
C 

CttTHt  TARGET  IS  AUDITORY 

C i • XE ( I ) -AMD I ENT  NOISE  LEVEL  IN  DB 

Ct4X0<  1 ) —TARGET  NOISE  LEVEL  IN  OB 

C«*XQ( 2) -TARGET  DURATION  IN  MINUTES 

C949N— SIGNAL- TO— NOISE  RATIO 

CitDATA  FROM  FLEISHMAN.  1473.  FACE  1143 

C 

1  SN—IO  <1)/XE(1> 

NME-MMEM 

NIV<NME>»3 

P<MMS>— 0.343+0. 0039  XO  (2) -0.02 1 9BN 
C 

C»*C ALL  ABBPHH  TO  DERIVE  SKILL  MODERATORS  FOR 
C  AUDITORY  RECOGNITION 
C 

CALL  A0SRMM(DIST.NIV.NME.F.XM> 

GO  TO  444 

c 
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i 


i 

p  * 


CUM  T ARPT!  IB  VISUAL 

C*4XTSK(2>»Tr®  OBSERVE*. -TO- TARGET  **08  IT  ION 

C4#NPOS«TN[  OBSERVER- TO-TARGCT  POSITION  AS  PM  INTEGER  VARIABLE 

C 

3  MP3B  ■NXMT<XTSK<2>> 

BO  TO  <3,4.9.  17.  18)1*08 
C 

C44TKI2  SB  A  SAOUND-TO-GROUND.  VISUAL  RECOGNITION  TASK 
C 

3  NMf*4M*t 
NIV(NME)«I 

p<nme>-dxst<i> 

c 

C44CALL  NIWW  TO  DCS XVI  SKILL  MODERATORS  POP 
C  GROUND- TO-6ROUNO.  VISUAL  RECOGNITION 
C 

CALL  RELPHM<DIBT,NIV.NHE.P,Xm 
00  TO  W 

c 

C44THIB  IS  «4  AIR-TO-GROUND.  VISUAL  RECOGNITION  TASK 
C44xo<3> -target  height  in  p*et 
C4*XQ(4>-TAP3ET  WIDTH  IN  FEET 

C44xo<9'-target  dcpth  in  feet 

C44X0<4>-0LANT  RANGE  TO  TARGET  IN  NAUTICAL  MILES 
r.itXPEET-*.ANT  RANGE  TO  TARGET  IN  FEET 

CitXSYARt^rHt  AVERAGE  OF  TV®  TARGET’S  THREE  PLANAR  AREAS  IN  SQUARE  YARDS 
CftXSHlL-ANOLE  (IN  SQUARE  MILS)  THAT  TV*  TARGET  SUBTENDS 
C44DA1  A  FROM  FRANKLIN  AND  WHITTtNBURS,  1*43,  PAGE  49 
C 

4  XFECT-X0<4> 44074. I 

XSVARD-<  <  (X0<3)  4X0(4)  >^(X0(3>  4X0(9)  > ♦ < XO (4) 4X0 <3> > > /3, O) /S. 0 
XSMIL»XSYARP4( <3000.0/ XFEtT) 4421 
IB®  ■!€»♦! 

NlV(NHE>-4 

P (NT®) -O. tl-O. 244 t EXP (-O. 000024 XSMIL442) 

C 

C44CALL  ABSPMH  TO  DERIVE  SKILL  MODERATORS  FOA 
C  AIR-TO-GROUND.  VISUAL  RECOGNITION  TASKS 
C 

CALL  ABSFMMtDIST.NIV.NW.P.XH) 
florow 
c 

C44rH:B  is  a  bround— to— air.  visual  recognition  task 
C44X0 (7) -HORIZONTAL  RANGE  TO  TARGET  IN  NAUTICAL  MILES 
C4 4X0 <8> -TARGET  TYPE 

C44XFH-HORIZONTAL  RANGE  TO  TARGET  IN  KILOMETERS 
C440ATD  FROM  WRIGHT.  1744.  PAGES  13.  14.  AND  17 
C 

9  XKH»K0<7>*a.t92 

IF  (XO(S).G^. 10.0)00  TO  U 
NHB-NHKM 
NlV (NME>  — 2 
NTARO-NINT(KO<B> ) 

BO  TO  (4.7.8.9.10  II. 12. 13. 14. |9>NTARS 
C 

C44TAR0ET  IS  AN  F-4C 

c 

4  P(NME)-0. 043*1. 0B24EXP(-0. 094XkM442> 

00  TO  14 
C 

C4STARGCT  IS  AN  F-lOO 

c 

7  P<NHI>-0. 004*1. 2l44EXP(-0.073*XKH«42> 

00  TO  14 

C 

CftTAROET  IS  A  f-33 
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c 


•  P  <NHE>«0. 023*1. 143tEXP<-0. 033 $XKAtt2) 

■0  TO  lt> 

C 

cttTARorr  s*  rj«rr>«p  type  op  jet 

c 

9  P<NAE>*0.01  +  l«10SffcvP<-0.032tU<AS«2> 

SO  TO  I* 

C 

CttTAAGCT  IS  A  IH1A 

c 

10  P<l#«)»0.03»0.444tEXP<-0.03aXW1t«2> 

SO  TO  I* 

c 

CtiTAAGET  JS  A  O-SA 

c 

tl  P<W«>-O.OOS*0.7E7tEXP<-O.OS2tXKAM2> 

SO  TO  IS 

c 

CttTAAOET  XS  ANOTXP  TYP«  OP  PPOPCUJCT  AIPCPAFT 

c 

12  Pt*t«>-O.0OS*O.4313EXP<-O.OAGtXKAtt2> 

so  ro  xs 
c 

CttTAAOET  XS  AN  Ol~* 

c 

13  P<NHE>«K).  010»0.  S13tf  XP<-C.074tXKASt2) 

SO  TO  IS 

c 

CttTAAOET  XS  AN  CM- 23 

c 

14  P<NNE>«0.©10*0« S134EXP  <— 0. 074tXKAS t2> 

SO  10  IS 

c 

CttTAAOET  XS  ANOTHER  TYPE  OP  HELXCOPTEP 
C 

13  P<NKE>-0. 004*0.  42B0£XP<-O.  10ifKKAtt2> 

C 

CttXQ<4>»SJN0CULAA  USAGE 

CttOATA  PAG ?i  WAICMT .  144S.  PAGE  14 

C 

15  NAE«t4ME*l 
NIVtNTtf  »-2 

IP  <X0<4).EQ.0.0>THEN 
C 

CttBINOCULAAS  NEPE  NOT  NO AN 

c 

P  <  NNE  >  »0 . 024*0 .  723 1 E  X  P  ( -O . 074 1  XKAf  1 2  ) 

ELSE 

C 

Ct t01f joculaps  here  noan 
C 

P<NAE>»0.  042*1. 03tEXP<-0.03tXKAtt2> 
EN01P 
C 

C 1 1 XQ  < 1 0  > •OWSEPYEP  OFFSET  IN  NAUTIC<4-  AXLES 
CttXH-CSSfcRVEP  OFFSET  IN  ASTERS 
CttOATA  FROM  HAIGHT »  1444.  PAGE  X3 
C 


NlV<NME>-2 
XA»»XO<  10)  tl8S2 

P<NAS>*0.S4O*O.  00003 tl*~0. 047 tXKA 
C 

CttCALL  ASSPWH  TO  DEPIVt  SKILL  AODEPATOAt  POP 
C  GROUND- T Q— A l A .  VISUAL  RECOGNITION 
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c 

CALL  AMTMNIDIST.NIV.NHE.F.XM) 

aonm 

c 

Cttmta  IS  AN  AIR-TO-AIR.  VISUAL  RECOGNITION  TASK 

c 

17  NHE<*rC-M 
NIV«NHC>>t 
F<Nh*>*>0IS1  <1> 

C 

C(*CALL  RELFMM  TO  DERIVE  SKILL  MODERATORS  FOR 
C  AIR-TO-AIR.  VISUAL  RECOQNITION  TASKS 
C 

CALL  RELFMHIDIST.NIV.NUt.R.XM) 

00  TO  TTY 
C 

C*«THIS  IS  A  VISUAL.,  DISPLAY-TARGET  RECOONITIION  TASK 
C 

IS  NNE-NMEtI 
NIV<NhE)-l 
P(NME>»D1STU> 

C 

CMCALL  RELPMH  TO  DERIVE  SKILL  MODERATORS  FOR  VISUAL, 

C  DISPLAY -TARGET  RECOGNITION 

c 

CALL  RELPMMIDIST.NIV.NMS.P.XM) 

00  TO  TTY 

c 

CtSTHlS  IS  A  REDUNDANT  AUDI  TORY/ VISUAL  TARGET  RECOGNITION  TASK 
C 

IS  NME-f***I 

N1V'M«>«I 

P<WC>-DIST<I) 

C 

CttCALL  RELFMM  TO  DERIVE  SKILL  MODERATORS  FOR 
C  REDUNDANT  AUDITORY/VISUAL  TARGET  RECOGNITION 

c 

CALL  RELPMM<DI8T.NIV.NMR.P.XM> 

VYV  RETURN 
END 
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Ct 

SUBROUTINE  RECQTWHDQ.  IDE,  N,  DIST,  ITASK.  NTS,  XH> 

C 

C( (MODULE* HUMAN  FACTORS  MODERATOR  FUNCTIONS 
C« (REFERENCE iMOPAD*/ VOLUME  9.10  DF 
C 

C( (PURPOSE* THIS  SUBROUTINE  RETURNS  1 1 ME- TO-RC COGNIZE  MODERATORS 
C  FOR  AUDITORY  AND/OR  VISUAL  RECOGNITION  TASKS 

C 

C** INRUT  PARAMETERS* 

C  IDO  (N>  -  ADDRESSING  INFORMATION  FOR  TWE  OPERATOR 

C  IDE (N)  -  ADDRESSING  INFORMATION  FOR  THE  ENVIRONMENT 

C  ITASK ( NTS)  -  ADDRESSING  INFORMATION  FOR  THE  TASK 

C  N  -  INDEX  FOR  IDO  AND  IDS 

C  NTS  -  INDEX  FOR  ITA8K 

C  DI8T (3)  -  NOMINAL  TAOK  PARAMETERS 

C  (1)  MEAN 

C  <?>  STANDARD  DEVIATION 

C  (3)  DISTRIBUTION  TYPE 

C 

C* •OUTPUT  PARAMETERS I 

C  XH(t>  -  SKILL  CATEGORY  MODERATOR  VALUES 

C  XMU)  -  DIFFERENCE  BETWEEN  DERIVED  AND  BASELINE 

C  MEAN 

C  XM(2)  •  DIFFERENCE  FC TWEEN  DERIVED  AND  BASELINE 

C  STANDARD  DEVIATION 

C  XM 13)  «  DERIVED  DISTRIBUTION  TYPE 

C 

Cm 

C ••LOCAL  VARIABLES! 

C  KO  -  NUMBER  OP  OPERATOR  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  K1  -  NUMBER  OF  ENVIRONMENTAL  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  NT  -  NUMBER  OF  TASK  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  HEO(KO)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  OPERATOR 

C  STATE  VECTOR 

C  NE*<KE>  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  ENVIRONMENT 

C  STATE  VECTOR 

C  NT  ASK  (NT )  -  ELEMENT  NUMBER*  OP  VARIABLES  IN  THE  TASK  VECTOR 

C  NME  -  NUMBER  OF  MODERATOR  EQUATION* 

C  NIMH)  —  NUMBER  OF  INDEPENDENT  VARIABLES  IN  MODERATOR 

C  EQUATION  I 

C  nil  -  TIME  TO  COMPLETE  CALCULATED  FROM  MODERATOR 

C  EQUATION  I 

C 

CF (DIMENSION  ARRAYS 

c 

DIMENSION  IDO(N).  !DE<N>.  D1ST<3>.  I  TASK (NTS) 

DIMENSION  NEO ( 4) •  NT9K(2).  NIV<3>.  Tl3>.  XM(3) 

DIMENSION  XO<4).  XTSK(2> 

C 

C • • D€F I NE  LENGTH  OF  ENVIRONMENTAL.  OPERATOR.  AND  TASK  STATE  VECTORS 
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c 

MTA  KO/4/ 

DATA  HTS2? 

C 

CSEOCFINB  NEEDED  L-EHfcNT  NUMBERS 

c 

DATA  W0/17.14.43.T2/ 

DATA  NTSK/3.4/ 

C 

CttOCFXNE  THE  VECTOR  ELEMENTS 

C  XO  (11-SLANT  RANGE  TO  TARGET  IN  NAUTICAL  NILE! 

C  XO<2(-TAR08T  DACKOAOUND  COMPLEXITY 
C  X0(3)»AIACNMrT  BREED  IN  KNOTS 
C  XO <41 -TARGET  TYRE 
C  XT8K< 11-TASK  MODALITY 

C  XTSK (21-THE  OS8ERVER-TO-TARQET  POSITION 
C 

C44RETRIEVE  VALUES  POP  OPERATOR  AND  TASK  STATE  VCCTOPS 
C 

CALL  SCTOVA  (IDO,  N.  NSO.  KO,  X0> 

C 

CMNTEK  CONTAINS  ELEMENT  NUHSCPS  OP  THE  TASK  SPECIFIC  HUMAN  PACTORS  DATA 
C 

IOPT-I 

call  ssttsa  uopt.  itask.  nts.  ntbk,  nt.  xtski 

c 

C4TINIT1ALIZE  NME.N1V 
C 

NHE-0 

MIVUl-O 

c 

COEVALUATE  XH 

CASXTSK 1  il-TASK  MODALITY 

C 

IP  (XTSK(l).EO.  1.0)00  TO  1 
IP  (XTSK(I).CO.IO.OIOO  TO  2 

ip  <xrsK(i).Eo.n.o>(io  to  s 
c 

cmthb  tapoet  is  auditory 
C 

1  MME-NME-l 
MI  V  04*1-1 
T(N«)-0I8T(I) 

c 

COCALL  RELTMH  TO  DERIVE  SKILL  MODERATORS  FOR 
C  AUDITORY  RECOGNITION 

c 

CALL  RELTISKDIST.NIV.NME.T.XH) 

SO  TO  444 

c 

CMTHE  TARGET  IS  VISUAL 

COXT8K(2l-THE  OBSERVER -TO- TARGET  POSITION 

CttNPOB-THE  OBSERVER- TO- TARGET  POSITION  AS  AN  INTEGER  VARIABLE 
C 

2  MR0AyNINT<XTSK(2)) 

90  TO  (3.4.3.4.71NPOS 

c 

CMTH1S  IS  a  GROUND- TO-OROUNO.  VISUAL  RECOGNITION  TASK 

c 

3  NMt*WMB+l 
NIV(NWE)— 1 
T04*I-DI9T<1> 

C 

COdALL  RELTMH  TO  DERIVE  SKILL  MODERATORS  FOR 
C  ORCUNO-TO-ORCUND.  VISUAL  RECOGNITION 

c 


£ 

> « 


if 


CALL  RELIHH<U18I.NIV,NME.  t.XU) 

00  TO  444 
C 

CttTHIt  *8  AN  AIR-TO-GROUND.  VISUAL  RECOGNITION  TASK 
CttXOU>»CLANT  RANGE  TO  TARGET  IN  NAUTICAL  MILES 
CttXPEET-SLANT  RANGE  TO  TARGET  IN  FEET 
CttXG  <2> -TARGET  BACKGROUND  COMPLEXITY 
CttDATA  FROM  BIEDEMAN.  GONER.  AND  LEVINS,  IS  BO, 

C  PAGES  104.  1SS 
C 

4  XFEET*X0<l>t4074.1 
NME-NME-M 
NIV<NMC)-2 

T<NME>-<-!3. 112*0. 001  tXFEET>l.I32tXO(2M/40.0 
C 

CttXQ<3> —AIRCRAFT  SPEED  IN  KNOTS 
CttXFTBEC-AIRCRAFT  SPEED  IN  FEET/SECOND 
CttDATA  FROM  BIEDEMA N.  GOMER.  AND  LEVINE.  1480. 

c  pages  104.  i:a 

c 

XFT9EC-X0(3> tl. ASS 

NM6-NME+1 

N1V  (Nh£  >  «1 

T  CNME>  •  <-4.341*0.  001  tXFEET-o.OIOtXPTSCC  1/60.0 
C 

CttX0(4> -TARGET  TYPE 

CttDATA  FROM  BIEDCMAN.  GOMER.  AND  LEVINE.  1480. 

C  PAGES  104.  1SB 
C 

CttTrtRGET  IS  A  TANK 
C 

IF  C XQ <  t  >  . EQ • 1 1 . 0 > THEN 
NME-NMC+1 
NXV  <NME> —2 

T<NMX>-<-1.44<K0.001tXFCET> /A0,.> 

END  IF 
C 

c*t TARGET  IS  A  HALF-TRACK 
C 

IF  <XQ<4> • CO. 17.0) THEN 
NMC-NME+1 
NIV<NME>-2 

T  < NMC )  •  ( - 1 2 . 37-^0 .  OO 1 1 XPEET )  / 40 .  0 
END  IF 
C 

CttTARGCT  IS  A  TRUCK 
C 

IF  (X0<4) . EQ. IS. OJ  THEN 
NHE-NME+l 
NIV<NME) —2 

T  <NME>- <-13.220*0. 001 IXFEET) /frO.O 
END  IF 
C 

.  CttCALL  ABGTMH  TO  DERIVE  SKILL  MODERATORS  FOR 
C  AIR-TO-GROUND.  VISUAL  RECOGNITION  TASKS 
C 

CALL  ABSTMMtDIST.NlV.NME.T.XH) 

00  10  944 
C 

CttfHlS  IS  A  GROUND-TO-AIR.  VISUAL  RECOGNITION  TASK 
C 

S  NME-NHC*1 
NIV<NME>-I 
T<NME>-DJBT<1> 

C 

CttCALL  RELTMH  TO  DERIVE  SKILL  MODERATORS  FOR 


a 

j 


ft 


Lc 


& 
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C  GROUND-TO-AIR.  VXBUAL  RECOGNITION 
C 

CALL  RCLTWH<DI8T.>*XV,NhE.T.Xm 
00  TO  *** 

c 

Ct (THIS  XI  AN  AIR-TO-AIR,  VXBUL  RECOGNITION  TASK 
C 

*  nhe-nhe+i 

NIV<NHE>-1 
T (NMK)*0XBT (1) 

C 

Ct (CALL  RCLTMH  TO  DERIVE  SKILL  MODERATORS  FOR 
C  AIR-TO-AIR.  VISUAL  RECOGNITION  TASKS 
L 

CALL  RELTNH(DIST.NIV.NNE.T,XH> 

00  TO  *** 

c 

Ct  (THIS  XS  A  VISUAL*  DISPLAY -TARGET  RECOGNITIION  TASK 
C 

7  NW-ft«+l 
NIV(NHE>-1 
T<NMB>-DX8T<1> 

C 

CttCALL  RELTNH  TO  DERIVE  SKILL  MODERATORS  FOR  VISUAL 
C  DISPLAY-TARGET  RECOGNITION 

c 

CALL  RCLTMH <DI8T.NIV.NNE.T.XH> 

00  TO  *** 

C 

CtCTHXS  It  A  REDUNDANT  AUDI TORY/ VISUAL  TARGET  RECOGNITION  TASK 
C 

S  NHC*NHEM 
NXV<NME>«I 
T<NHE>-DI8T<1> 

C 

CttCALL  RELTMN  TO  DERIVE  SKILL  MODERATORS  FOR 
C  REDUNDANT  AUDI TORY/ VISUAL  TARGET  RECOGNITION 
C 

CALL  RELTMH(DIST.NXV.NME.T.XN) 

W  RETURN 
END 
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Cl 

SUBROUTINE  STSYPH<IDO.  I  DC.  N.  DX3T.  ITASK,  NTS,  X«>  ' 

C 

CttMODULCl HUMAN  FACTORS  MODERATOR  FUNCTION* 

CMRCFERENCE*  MOP  ADS /VOLUME  3.10  DF 
C 

CttPURPGSE*  THIS  SUBROUTINE  RETURNS  PROBABILITY  TO  COMPLETE 
C  SHORT-TERN  MEMORY /SENSORY  TASKS 

C 

CM  INPUT  PARAMETERS* 

C  IDO (N)  -  ADDRESS I NO  INFORMATION  FOR  THE  OPERATOR 

C  IDE <N)  -  ADDRESSING  INFORMATION  FOR  THE  ENVIRONMENT 

C  I TASK (NTS)  -  ADDRESSING  V  FORMATION  FOR  THE  TASK 

L  N  -  INDEX  FOR  IDO  AND  IDE 

C  NTS  -  INDEX  FOR  ITASK 

C  DXBT (3)  -  NOMINAL  TASK  PARAMETERS 

C  U>  MEAN 

C  (2>  STANDARD  DEVIATION 

C  <3)  DISTRIBUTION  TYPE 

C 

CM  OUTPUT  PARAMETERS* 

C  XH(I>  -  SKILL  CATEGORY  MODERATOR  VALUES 

C  XMU)  •  DIFFERENCE  BETWEEN  DERIVED  AND  BASELINE 

C  MEAN 

C  KM (2)  •  DIFFERENCE  BETWEEN  DERIVED  AND  BASELINE 

C  STANDARD  DEVIATION 

C  XM<3>  •  DERIVED  DISTRIBUTION  TYPE 

C 


Cl  » 

CM  LOCAL  VARIABLES* 


C 

c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 

CM  DIMENSION  ARRAYS 

c 

DIMENSION  IDO (N> .  IDE(N). 
DIMENSION  NEOU).  NTSK<2> 
DIMENSION  XQU).  XTBK<2) 

c 

CM  DEFINE  NEEDED  ELEMENT  NUMBERS 
C 


KO  -  NUMBER  f  OPERATOR  INDEPENDENT  VARIABLES  USED  IN 
THIS  MODERATOR  FUNCTION 

KE  -  NUMBER  OF  ENVIRONMENTAL  INDEPENDENT  VARIABLES  USED  IN 
THIf  MODERATOR  FUNCTION 

NT  -  NUMBER  OF  TAPK  INDEPENDENT  VARIABLES  USED  IN 
THIS  MODERATOR  FUNCTION 

NEO (KO)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  OPERATOR 
STATE  VECTOR 

NEI(KE)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  ENVIRONMENT 
STATE  VECTOR  I, 

NT  ASK (NT)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  TASK  VECTOR 

NME  -  NUMBER  OF  MODERATOR  EQUATIONS 

NIVCI)  -  NUMBER  OF  INDEPENDENT  VARIABLES  IN  MODERATOR 
EQUATION  I 

P(!>  -  PR08ABILITY-T0-C0MPLETE  CALCULATED  FROM  MODERATOR  EQUATION 


iMpLE 


DIST (3> •  ITASK (NT9) 
Nl V ( 2) •  P (2) •  XM<3> 
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DATA  NEO/3/ 

DATA  MTSK/li* 1/ 

DATA  NIV/2# 1/ 

C 

Cl* THE  VECTOR  ELEMENTS  /‘RE  AS  FOLLONSl 
C  XOU)»TIME  ON  TASK 

C  XT8X  ( 2  ) "NUMBER  OF  ITEMS  KEPT  IN  SHORT  TERM  MEMORY 
C  XT6K <2 >-KCAL/ MINUTE  REQUIRED  OF  THE  TASK 

C 

CMRETRIEVE  THE  VALUES  FOR  THE  STATE  VECTORS 
C 

CALL  GETOVA  < IDO.N.NEO.KO,  XO> 

CALL  OCTTffA< I. ITA8K.NT8.NTSK, NT. XT8K) 

C 

Cl* INITIAL! ZE  NMC 
C 

NME-0 

C 

CMEVALUATE  XM 

CIIDATA  FROM  BIEOEL  ET  AL  lY7f 
C 

NME-NHEM 

P <NHE> -DI8T < 1 ) t < < 1. ! 1-. 2tXTSK • i ) ) ♦ 0R3*. 22IXTBK < I ) ) • 

♦  EXP ( (-•044-.O43IXTBK <l)>tXO(l)>) 

C 

c 

CMDATA  FROM  DAVEY(1P73) 

C 

NME«NME+1 

IF  <XTSK (2) . LTt  2. 0)  THEN 

P (NME) »DIST  ( 1 ) t (l+» 023IXTBK (2) ) 

ELSE 

P  <  NHE  >  -  D  X  S  T  <  I )  *  (1 .  OS- .  0  23  •  X  T  SK  <  2 ) ) 

ENDIF 

C 

ClfCALL  RELPMH  TO  DERIVE  SKILL  MODERATORS  FOR  PRO BAB X L I TY-TO-COMPLETE 
C 

CALL  RELPMH CDI5T,  NIV.  NHE.  P.  XM> 

RETURN 


Cl 

•USMOUTINC  »T»YTM(IDO.  IOC.  N.  OICT.  STACK.  NTS.  «M> 

C 

CHHOWJLClUjrW*  FACTORS  MODERATOR  FUNCTIONS 
CttREFERSNCElNCRADS/VOUJHt  S.  10  OK 

c 

C*»Pl«POSSlTHIS  CUmUTlK  RETURNS  TIfC  TO  CORSLETS 
.  C  TACKS  WHICH  REQUIRE  SHORT-TERM  MEMORY /SENSORY 

'  c 

CIIINPUT  RARAMETEWSi 

C  I  COIN)  -  AODRESBINQ  INFORMATION  FOR  TMC  OPERATOR 

C  IOC  IN)  -  ADDRESSING  INFORMATION  FOR  THE  ENVIRONMENT 

C  I  TACK  (NFS)  -  ADDRESSING  I^ORHAT  ION  FOR  THE  TACK 

C  N  -  INEZ I  FOR  ICO  AND  IOC 

C  NTS  -  I NOCK  FOR  1  TASK 

C  DIST  (3)  -  NOMINAL  TASK  PARAMETERS 

C  a>  HCAN 

C  (2)  STANDARD  DEVIATION 

C  (3)  DISTRIBUTION  TYFC 

c 

OfOUTRUT  RARRHCTCRSl 

C  INI  I)  -  SKILL  CATEGORY  HOOERATON  VALUES 

C  IN  v  I )  «  DIFFERENCE  BETWEEN  DERIVEU  mND  BASELINE 

C  hean 

C  XH<2>  *  DIFFERENCE  BETWEEN  DERIVED  AND  BASELINE 

C  STANDARD  DEVIATION 

C  «n<3)  •  DERIVED  DISTRIBUTION  TYRE 

c 

Cl  • 

CtILOCAL  VARIABLES) 

C  KO  -  NUFISCR  OF  ORERATOR  INOEFENOENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  MJNC-TOI 

C  Kt  -  NUN8E"  OF  ENvm^CTMAL  INOEFENOENT  VARIABLES  USED  IN 

C  THU  MOOEAATLN  FLY  0  T I  ON 

C  NT  -  NUHCCR  OF  TASK  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  NEOIKO)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  OPERATOR 

C  STATE  VECTOR 

C  NEE  IKE)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  ENVIROICCNT 

C  STATE  VECTOR 

C  N1ACKINT)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  TASK  VECTOR 

C  NT*  -  NUMBER  OF  MODERATOR  EQUATIONS 

C  N1VII )  -  NUMBER  OF  INDEPENDENT  VARIABLES  IN  MODERATOR 

C  EQUATION  I 

C  Till  -  TIF*  DELAY  CALCULATED  FROM  MODERATOR  EQUATION  I 

C 

Cl IDI  MENS  ION  ARRAYS 
C 

DIMENSION  IDO  IK) ,  IDE  IN) .  DIST(J).  1  TASK  I NTS) 

DIMENSION  NIV  ( I  >  .  Til).  KM  (3) 

C 

CIIINIT IALI2E  NFC. NIV 
C 

M(B«0 


R— 7  9 


mvin-w 

e 

CktavMoMTt  m 

c««mo  mta  men  mm  r o  rmoier  Tim  to  comxrc  thnco  which  mouim 

C«*  ■HOWT-TOH  mHORY/KXepHY 
WIHIM 
NIVINMU-I 
T(Nm>-DI«TII) 

c 

cucacl  fliLTHH  to  dcwivc  skill  nooerwTows  row  rim  to  comurrc 
c 

CALL  MLTMHIOItT.NIV.Mm.T.xm 

WKTUSN 

DO 
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Ct 


c 


SUBROUTINE  im»H<!DQ.  IDE.  N.  OUT,  ITASK.  NTS*  XM> 


CttRCDULKi HUMAN  FACTORS  HQDEAAVTR  FUNCTIONS 

ctcssFcmct:X)F«os/\ixur«  3. 10  of 

C  ••PURPOSE*  THIS  SUBROUTINE  AETl*NB  PROBABILITY  TO  COMPLETE 

c  smort-tirm  rertoNY/smsoLtc  taqks 

CttJNPUT  PARAMETERS* 

C  !DO(N>  -  ADORESRXNS  INFORMATION  FOR  THE  OPERATOR 

C  SOS <N>  -  A©0«*39IH0  I.#Om*TIJN  for  the  environment 

C  I  TASK  «NTS>  -  FODRCMINS  INFORMATION  FOR  THS  TASK 

C  N  •  IYOCX  FOR  toe  and  ZOt 

C  NTS  -  INDEX  FOR  1  TASK 

C  BIST  (3)  -  NOMINAL  TASK  PAAAMITERS 

C  <1>  MEAN 

C  <2>  STANDARD  0SVIATX0N 

C  <3>  DISTRIBUTION  TYPE 

CtMUTFUT  PARAMETERS* 

C  XMU>  •  SKILL  CATE0ORV  VALUES 

C  »m)  -  DIFFERENCE  BCTHEEN  DERIVED  AND  BASEL  INS 

C  «AN 

c  BH<2>  •  difference  bstvtzm  d erxved  and  baseline 

C  STAN!>AR©  DEVIATION 

c  wi<3>  •  derived  distribution  tyfs 


Cii 

CttUXAL  VAAIASLSSl 

C  KXJ  -  NUMBER  OF  OPERATOR  XtNXfftMKN?  VARIABLES  USED  IN 

C  THIS  ImXERATOH  FUNCTION 

C  KI  -  NUMBER  CF  ENVIRONMENTAL  INDEPENDENT  VAAIABUES  USED  IN 

C  THIS  HUOERATOR  FUNCTION 

C  NT  -  NUMBER  OF  TACK  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTIiX 

C  «EO<KO>  -  ELEMENT  MJM8CRS  OF  VARIABLES  IN  THE  OPERATOR 

C  STATE  VECTOR 

C  NBS(KE>  -  ELEMENT  NUMBERS  OF  VAAIAOLSS  IN  THE  ENVIRONMENT 

C  STATE  VECTOR 

C  NTASK  <NT  >  -  ELEMENT  NUMBERS  OF  VARIABLES  IK  THE  TASK  VECTOR 

C  M  -  NUMBER  OF  MODERATOR  EQUATIONS 

C  NIV(I)  -  NUMBER  OF  INDEPENDENT  VARIABLES  IN  MODERATOR 

C  EQUATION  I 

C  P<I>  -  RROSASILITt-TO-COMRLETE  CALCULATED  FROM  MODERATOR  EQUATION  I 

c 

C* •DIMENSION  ARRAYS 
C 

DIMENSION  IDO  (N) •  IDE  IN)  •  0IST<3>.  ITASK <NTS> 

DIMENSION  NEO(I).  NTSK (2) .  NXVI2).  P<2>.  XM<3> 

DIMENSION  XO<S>.  XTSK(2) 

c 

Cf •DEFINE  ^ CEDED  CLEMENT  NUMBERS 
C 
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/ 


MMtt  MtU/Ss 
DATA  NTMC/11.1/ 

BATA  MIV/2.1/ 

C 

C*»TMt  VCCTOA  aMMTI  AM  M  raLLOLBi 
C  ItUl-TIMB  ON  TASK 

C  «T«Kii>a*uiKR  or  im  icsrr  in  mat  ram  im*y 
c  (TiK<2»KCAL/niMrrt  acquircs  cr  thb  tack 

c 

c*«Armitvt  thb  vaujks  ran  thb  stati  vbctqrb 
c 

CALL  Berov*  (IBO.N.tCO.KO.XO) 

CALL  NBTTBAU.XTABK.NTB.NTBK. NT. XTIKl 

c 

CBtXNITXALXZB  MNB 
C 

NNB*0 

C 

CtSBVAUJATt  IN 

CMOATA  raON  BXUBL  KT  AL  1*7* 

e  » 

N<HM>-DI»TU>*(U,11-.2»XTBKU>>*<-.0*S*.23«XTBKU>>« 
♦  cia:(-.044-.043(xt*ki>)>*xou>>> 

c 
c 

cmoaxa  men  &*vevu*rs> 
c 


IN  CXTBK<2>.LT.2.0>  THBN 

N(NHB>>OIBTUI  «U».029«XTBX<2> ) 


it 


r  (NHB>  -OUT  U  >  *  ( 1 .  OS- .  02SAXTBX  (21 » 

BHOXN 

C 

CMCALL  R2LAHH  TO  DBJUVB  (KILL  NOSCNATCM  NON  PAOBABILITV-TO-COMUCTI 

c 

CALL  *«L»>tW<01»T.NIV.NHB.N.XH> 

ABTUNN 

BNO 

* 


R-82 


! 


I 

I 

m 

v. 

k 


Ci 


subroutine  stwthudo.  ioc.  n ,  dist.  itask.  nts.  xh> 


C3  •MODULE*  HUN#  I  FACTORS  EJDCRATOR  FUNCTIONS 
C<  (REFERENCE  I MOPADS/ VOLUME  9.  10  OF 

c 

Ct*PUPPt»ElTHlS  SUBROUTINE  RETURNS  TIMS  TO  COMPLETE 
C  TAM  MNICH  REQUIRE  SHORT-TERM  MEMORY /SYMBOLIC 

C 

Ctt INPUT  PARAMETERS) 


100 IN)  -  ADDRESSING  INFORMATION  TON  fh«  OPERATOR 

I  DC  <N)  -  AODRE5SIN0  INFORMATION  FOR  THE  ENVIRONMENT 

1  TASK  (NTS)  *  ADDRESSING  INFORMATION  FOR  THS  TASK 

N  -  INDEX  FOR  100  AND  I DC 

NTS  -  INDCX  FOR  I TASK 

GIST  (3)  -  NOMINAL.  TASK  PARAMETERS 

(1)  MEAN 

(2)  STANDARD  DEVIATION 

(3)  DISTRIBUTION  TYPC 


c 
c 
c 
c 
c 
c 
c 
c 
c 
c 

C ••OUTPUT  RARRHKTCRSl 
C  XH<1)  -  SKILL  CATEGORY  MODERATOR  VALUES 


C 
c 
c 
c 
c 
c 

Csi 

C« (LOCAL 

c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 

Ct tD! MENS ION  ARRAYS 

c 

01 PENSION  IDO(N). 
DIMENSION  NIV(1). 

r 

cmrtn  1ALIZC 

c 

NWC-* 


DIFFERENCE  BETWEEN  DERIVED  AND  SASH. IMF 
MEAN 

XH<2>  -  DIFFERENCE  BETWEEN  DERIVED  AND  BAEXXINC 
STANDARD  deviation 

XH<3)  e»  derived  distribution  TYT*C 


VARIABLES! 

KO  ~  NUMBER  OF  OPERATOR  INDEPENDENT  VARIABLES  USED  IN 
THIS  MODERATOR  FUNCTION 

K8  •  NUMBER  OF  ENVIRONMENTAL  INDEPENDENT  VARIABLES  USED  IN 
THIS  MODERATOR  FUNCTION 

NT  -  NUMBER  OF  TASK  I NDtTPEXOCNT  VARIABLES  USED  IN 
THIS  MODERATOR  FUNCTION 

NEO(KO)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  OPERATOR 
STATE  VECTOR 

NEt(KE)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  ENVIRONMENT 
STATE  VECTOR 

NT  ASK  (NT)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  TASK  VECTOR 

NME  -  NUMBER  OF  MODERATOR  EQUATIONS 

NIV(I)  -  NUMBER  OF  INDEPENDENT  VARIABLES  IN  MODERATOR 
EQUATION  I 

f (I>  -  TIME  DELAY  CALCULATED  FROM  MODERATOR  EQUATION  I 


IDS  <N> •  f*ST(3). 

Tea*.  iMtj> 


ITASK (NTS) 


m 


r* 

& 


I.NIV 
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9 

ft 


v 


f 

* 


Ml vili*g 


e 

UCtCVALUATC  XH 

CttMO  OA'.A  NCRC  FOUND  TO  PACDICf  Til*  TO  COHAIXTI  TWO  WHICH  NCOUIMt 

cm  anoMT-TinH  r'XHOHv/ivraoLic 
wm»i 
Niviwwn-i 
TIM)«D1IT(II 

c 

C»«CALL  AIlTHH  TO  DCF  I  VC  IK  ILL  HOOCHATOHC  FTJA  T1HC  TO  COFCIXTt 
C 

CALL  HCLTHH(DI»T.NIV.NMC.T.XH> 

nCTUNN 

UNO 


R-84 


SUBROUTINE  TKAflPHtSSO. 


I TASK.  NTS,  Iff) 


<2>  STANDARC  DEVIATION 
(3)  DISTRIBUTION  T YPC 


CttlNITIALIZE  NME.NIV 
C 

NMC-O 


CMHODULCt HUMAN  FACTORS  MODERATOR  FUNCTIONS 
CMREFCRENCEtHOPADS/VOLUHI  9.10  DF 
C 

CMPUAPOCCi  THIS  SUBROUTINE  RETURNS  PROS  ABILITY  TO  COMPUfTE 
C  TEAM  COORDINATION  TASKS 

c 

CM  INPUT  PARAMETERS* 

C  100  ( N>  -  AOFCSSINO  1  FORMAT  I  ON  FOR  THE  OPERATOR 

C  IOC  (K)  -  ADDRESSING  INFORMATION  TOR  HE  ENVIRONMENT 

C  I  TASK  (NTS)  -  ADDRESSING  INFORMATION  *CR  THt  TAS< 

C  H  -  INDEX  FOF  IDO  AND  IOC 

C  NT*  -  INDEX  FOR  *TA3K 

C  OIST (3)  -  NOMINAL  TASK  PARAMETERS 


CMOUTPUT  PARAMETERS! 

C  Xh<I>  -  SKILL  CATC90RY  MODERATOR  VALUES 

C  XMCl)  -  Pirt^fcMCS  BETWEEN  DERIVED  ANO  BASELINE 

C  MEAN 

C  XM<2>  -  DIFFERENCE  BETWEEN  DERIVED  AND  S*'4HELXN8 

C  STANDARD  DEVIATION 

C  XM<3)  -  DERIVED  DISTRIBUTION  TYPE 

C 

Cl  t 

CMLOCAL  VARIABLES! 

C  KO  -  NUMBER  OP  OPERATOR  INDEPENDENT  VALUABLES  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  Ft  -  NUMBER  OF  INV I ROMMCN T AL  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  MOOCRATOR  FUNCTION 

C  NT  -  NUMBER  OF  TASK  INDEPENDENT  VARIABLES  ('‘SCO  IN 

C  THIS  MODERATOR  FUNCTION 

C  NtO<FO>  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  OPERATOR 

C  STATE  VECTOR 

C  NEC <KE>  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  ENVIRONMENT 

C  STATE  VECTOR 

C  NT  ASK  (NT)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  TASK  VECTOR 

C  NME  -  NUMBER  OF  MODERATOR  EQUATIONS 

C  NIV<I)  -  NUMBER  OF  INDEPENDENT  VARIABLES  IN  MOOCRATOR 

C  EQUATION  t 

C  P(!)  -  PROBABILITY- TO- COMPLETE  CALCULATED  FROM  MQOERATCtf  EQUATION  I 

C 

C* •DIMENSION  ARRAYS 

c 

DIMENSION  XDO(N).  IDC(N).  DIST(3).  XTAJK(NTS> 

OIMENSXON  NIV(I).  F < 1 ) .  XM(3) 


/ 


HIV  U>«© 


r 

CittVALlMTC  XH 

C$*NO  DATA  H£«  FOUND  TO  PREDICT  PAOIWUnLITY-TO-COMPLITS 
wll  TEAM  COORDINATION  TASKS 
C 

NHE-NHB+1 

NIVCNHR)-! 

P<NME>*DIST<1, 

C 

CttCALL  RELPNM  TO  DERIVE  SKILL  MODERATORS  FOR  PROBABILITY -TO-COMPLET1 
C 

CALL  RCLPMH<DIST.NXV.NME.P.XH) 

RETURN 

■HD 
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& 

.4 


3 


Cl 

subroutine  teahthmdo.  ide.  n.  oist.  2 task,  ntb.  xm> 

c  ■ 

CMMGDULEl  HUMAN  FAC  TOM!  MODERATOR  FUNCTIONS 
Ct PREFERENCE i MOP ADS /VOLUME  3.10  OF 

c 

Ct •PURPOSE*  THIS  SUBROUTINE  RETURNS  TIME  TO  COMPLETE 
C  TASKS  WHICH  REQUIRE  TEAM  COORDINATION 

C 

CM  INPUT  PARAMETERS! 

C  100 (N)  -  ADDRESSING  INFOhHATION  FOR  THE  OPERATOR 

C  1DC(N)  -  ADDRESSING  INFORMATION  FOR  THE  ENVIRONMENT 

C  1  TASK (NTB)  -  ADDRESSING  INFORMATION  FOR  TV*  TASK 

C  N  -  INDEX  FOR  IDO  AND  IDE 

C  NTS  -  INDEX  FOR  I TASK 

C  DIST (3)  -  NOMINAL  TASK  PARAMETER* 

C  <i>  MEAN 

C  <2>  STANDARD  DEVIATION 

C  <3>  DISTRIBUTION  TYPE 

C 

Cl •OUTPUT  PARAMETERS* 

C  xml)  -  SKILL  CATEGORY  MODERATOR  VALUES 

C  XM<I>  -  DIFFERENCE  BETWEEN  DERIVED  AN*)  BASELINE 

C  MEAN 

C  XM (2)  •  DIFFERENCE  BETWEEN  DERIVED  AND  EASELINE 

C  STANDARD  DEVIATION 

C  XH<3>  •  DERIVED  DISTRIBUTION  TYPE 

C 

Cl» 

C* • LOCAL  VARIABLES! 

C  KO  -  NUMBER  OP  OPERATOR  INDEPENDENT  VARIABLES  USED  IN 

C  MODERATOR  FUNCTION 

C  «  -  NUMBER  OP  ENVIRONMENTAL  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  NT  -  NUMBER  OF  TASK  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  NCO<KO)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  OPERATOR 

C  STATE  VECTOR 

C  MEC<KE>  *  ELEMENT  NUMBERS  OP  VARIABLES  IN  THE  ENVIRONMENT 

C  STATE  VECTOR 

C  NTASKtNT)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  TASK  VECTOR 

C  NHE  -  NUMBER  OF  MODERATOR  EQUATIONS 

C  N2V < I )  -  NUHDER  OF  INDEPENDENT  VARIABLES  IN  MODERATOR 

C  EQUATION  I 

C  MI)  -  1 1 ME  DELAY  CALCULATED  FROM  MODERATOR  EQUATION  I 

C 

Ci t DIMENSION  ARRAYS 
C 

DIMENSION  2  DO  <  N) ,  IOC(N).  DIST<3> .  I  TASK (NTB) 

DIMENSION  HI V<1>.  Ml).  XM<3) 

C 

CMIMITIALI2E  NME.NIV 
C 


ft 


£ 


J 


K* 


?! 

0 


1 
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J 


HME— > 


Ml  VI  !>«*.* 


C 

CMIVALUATS  X.1 

CttNO  DA fA  MC RC  FOUND  TO  FRCDICT  TXKX  TO  CONFUTO  TASKS  WHICH  REQUIRE 
CM  TEAM  COORDINATION 
NHE«NME+1 
HIV(NHK>«1 
r<NNK>«DXST<l> 

c 

CttCALL  RELTMH  TO  OERIVC  SKILL  MODERATORS  FOR  TIME  TO  COMPLETE 
C 

OX  RELTMH <DXBT.N1V.NME.T.XH> 

RETURN 

END 


R-88 


s  ■? 


Cl 

SUBROUTINE  TMCSPHUDO.  SDC.  N.  DI8T.  I  TASK,  NTS.  XN> 

C 

CMMODULEi  HUMAN  FAC  TOTS  MODERATOR  FUNCTIONS 
C*«R€FER£NCEi MOPAOS/VOLUME  S. 10  OF 
C  i 

CMPURPOSEi  THIS  SUBROUTINE  RETURNS  PROBABILITY  OF  COMPLETING 
C 

c 

CM  INI 
C 

c  • 
c 
c 
c 
c 
c 
c 
c 
c 

CMOUTPUT  PARAMETERSi  ] 

C  XMU)  -  SKILL  CATEOORY  MODERATOR  VALUES 

C  Xtt(l)  •  DIFFERENCE  BETWEEN  DERIVED  AND  BASELINE 

C  MEAN 

C  XM (2)  -  DIFFERENCE  BETWEEN  DERIVED  AND  BASELINE 

C  STANDARD  DEVIATION 

C  XK<3)  -  DERIVED  DISTRIBUTION  TYPE 

C 

Cs  i 

C* "LOCAL  VARIABLES* 

C  KO  -  NUMBER  O*  OPERATOR  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  Kt  -  NUMBER  OF  ENVIRONMENTAL  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  NT  *  NUMBER  OF  TASK  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  NEO <KQ)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  OPERATOR 

C  STATE  VECTOR 

C  NEC  IKE)  -  ELEMENT  NUMBERS  OP  VARIABLES  IN  THE  ENVIRONMENT 

C  STATE  VECTOR 

C  NTA3K  *.NT>  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  TASK  VECTOR 

C  NME  -  NUMBER  OF  MODERATOR  EQUATIONS 

C  NIVU)  -  NUMBER  OF  INDEPENDENT  VARIABLES  IN  MODERATOR 

C  EQUATION  I 

C  P<  I)  -  PROBABILITY- fO- COMPLETE  CALCULATED  FROM  MODERATOR  EQUATION  I 

C 

CMOI MCNSIQN  ARRAYS 

c 

DIMENSION  1D0(N).  ID€(N).  013T<3>.  ITASK<NT8> 

DIMENSION  NIVU).  P<1>.  XM<3> 

C 

CMINITIALIZF  NME.NIV 
C 

NHE-O 


R-89 


TASKS  WHICH  RE 

r  PARAMETERS! 

IDO  <N)  -  ADDRESS! 

IDE (N)  -  ADDRESS I 
1  TASK (NT3>  -  ADDRESSING  INFORMATION  FOR  THE  TASK 
N  -  INDEX  FOR  IDO  AND  *DK 
NTS  -  INDEX  FOR  ITASK 
DI8T (3)  -  NOMINAL  TASK  PARAMETERS 
U>  MEAN 

(2)  STANDARD  DEVIATION 
(3>  DISTRIBUTION  TYPE 


Eire  the  estimation  of  time 

INFORMATION  FOR  THE  OPERATOR 
INFORMATION  FOR  THE  ENVIRONMENT 


£ 


K 

Jfc? 


rw 

M 

^  & 

W  tJ 

^  fs 

tS 

IN  iS* 
J  (j-i 


tl  M 

n  i*;. 

►  \ 


i  * 


NXV<i>-0 


c 

CM  EVALUATE  KM 

CMNO  DATA  MERE  FOUND  TO  PREDICT  PROBASJTY  OF  COMPLETING  TASKS  WHICH 
CM  REQUIRE  THE  ESTIMATION  OF  TIME 
NME-NMEM 
NIV(NM^)-! 

P<NHE>-DI8T(I> 

C 

CM  CALL  RELPMH  TO  DERIVE  SKILL  MODERATORS  FOR  PROBAt'ILITY-TO-COMPt-ETE 
C 

CALL  RELPMH <DIST.N IV. NME.P.Xrt) 

RETURN 

END 


R*90 


Ci 


SUBROUTINE  TMCfJTHUDO.  2 DC.  N,  DIET.  XTA8K,  NTS.  XH> 


C 

C I  t NODULE I  HUMAN  FACTORS  MODERATOR  FUNCTIONS 
C*  •  REFERENCE  I  MOP ADS/ VOLUME  1.10  DP 
C 

CMrURPOSEtTHIS  SUBROUTINE  RETURNS  TIME  TO  COMPLETE 
C  'ASKS  WHICH  REQUIRE  THF.  ESTIMATION  OP  TIME 

C 

Ct • INPUT  PARAllETERSi 

C  IPO (N)  -  ADDRESSING  INFORMATION  FOR  THE  OPERATOR 

C  IDE  (N)  -  ADDRESSING  INPORMATION  FOR  THE  ENVIRONMENT 

C  I  TASK (NTS)  -  ADDRESSING  INFORMATION  FOR  THE  TASK 

C  N  -  INDEX  FOR  IDO  AND  IDE 

C  NIS  -  INDEX  FOR  I  TASK 

C  D19T (3)  -  NOMINAL  TASK  PARAMETERS 

C  U>  MEAN 

C  (2)  STANDARD  DEVIATION 

C  *  <3)  DISTRIBUTION  TYPE 

C 

C* •OUTPUT  PARAMETERS! 

C  XH«I>  -  SKILL  CATEGORY  MODERATOR  VALUES 

C  XH (!)  »  DIFFERENCE  BETWEEN  DERIVED  AND  BASELINE 

C  MEAN 

C  XH<2>  -  DIFFERENCE  DETWEEN  DERIVED  AND  BASELINE 

C  STANDARD  DEVIATION 

C  XM (3)  -  DERIVED  DISTRIBUTION  TYPE 

C 

Ci  i 

C* « LOCAL  VARIABLES! 

C  KO  -  NUMBER  OF  OPERATOR  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  KI  -  NUMBER  OF  ENVIRONMENTAL  INDEPENDENT  VARIABLES  US«D  IN 

C  THIS  MODEPATOR  FUNCTION 

C  NT  NUMBER  OF  TASK  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  MEO<KO>  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  OPERATOR 

C  STATE  VECTOR 

C  NCE(KE)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  ENVIRONMENT 

C  STATE  VECTOR 

C  HI ASK (NT)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  TA8K  VECTOR 

C  NMC  -  NUMBER  OF  MODERATOR  EQl*ATIONS 

C  HIV  (!)  -  NUMBER  OF  INDEPENDENT  VARIABLES  IN  MODERATOR 

C  EQUATION  I 

C  MI)  -  TIME  DELAY  CALCULATED  FROM  MODERATOR  EQUATION  I 

C 

C ••DIMENSION  ARRAYS 
C 

DIMENSION  IDO (N) .  IDE(N).  DI3T(3>,  ITASK (NTS) 

DIMENSION  NJVM>.  Ml).  XM(3> 

C 

CttlNIl IAL1 ZE  NME.NIV 
C 

MHE-» 


R-Sl 


SUBROUTINE  TIMER* (IDO.  ZM.  N.  DIET.  XTABK.  NTS.  XH> 

C 

C9«HCDUUti  HUMAN  FACTOR*  mooerator  function* 

C  9  9RCFERENCE  a  MOPADS/ VOLUME  9.10  OF 

c 

CttFURPOSCl  THIS  MWUT1NI  RETURN*  PROBABILITY  TO  COMPLET* 

C  TIMESHARCD  TMKI 

c 

C« • INPUT  PARAMETERS* 

C  100 (N)  •  AOORCBFINO  INFORMATION  FOR  THE  OPERATOR 

C  1DC <N)  -  ADDRESSING  INFORMATION  FOR  THE  ENVIRONMENT 

C  1  TASK  (NT*)  -  ADDRSMINO  INFORMATION  FOR  THE  TASK 

C  N  -  IKOtX  FOR  100  AND  IOC 

C  NT*  -  I NOCK  FOR  I  TASK 

C  02«T<3)  -  NOMINAL  TACK  PARAMETERS 

C  (2)  STANOARO  DEVIATION 

C  (3)  DISTRIBUTION  TVFC 

C 

C99CUTPUT  PARAMETERS! 

C  KM<I>  -  SKILL  CATEGORY  MODERATOR  VALUE* 

C  XM(i>  -  DIFFERENCE  FCTNECM  DERIVED  AND  BASELINE 

C  M CAN 

C  *H(2>  -  DIFFERENCE  BCTNE'/N  DERIVED  AND  BASCLINC 

C  STAHT*ARD  DEVI  AT  I  ON 

C  XM<3>  •  DERIVED  DISTRIBUTION  TYPE 

C 

Cti 

C* (LOCAL  VARIABLES i 

C  KO  -  MUHBCR  OF  OFCRATOR  I NDCPCNCCNT  VARIABLE*  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  KC  •  NUMBER  OF  ENV IROMMCNTAL  INDEPENDENT  VARIABLE*  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  NT  -  NUMBER  OF  TASK  INDEPENDENT  VARIABLES  USED  IN 

C  THt*  MODERATOR  FUNCTION 

C  NEO(KO)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  OPERATOR 

C  STATE  VECTOR 

c  nee (ke>  -  element  numbers  of  variables  in  the  environment 

C  STATE  VECTOR 

C  NT  ASK  (NT)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  TNI  TASK  VECTOR 

C  NMC  -  NUMBER  OF  MODERATOR  EQUATIONS 

C  N1V(!  I  -  NUMBER  OF  INDEPENDENT  VARIABLES  IN  MODERATOR 

C  EQUATION  S 

C  Fill  -  PROBED IL I TT-TO-COMPLETE  CALCULATED  FROM  MODERATOR  EQUATION  I 

C 

C 9 90 I MENS 2 ON  ARRAYS 
C 

DIMENSION  I  DO  <N> •  IDE (N) .  DIST(3).  2  TASK (NTS) 

DIMENSION  NIVO  I.  P(t).  XM  (3) 

C 

CtilHITlALlZC  NME.NIV 
C 

HMt-0 


c 

C 


< 

\ 

% 

\ 

% 

,N 


I 

A 

•* 

I 


V 

i 


i- 

(•; 

t* 

§ 

n 

)>. 

N 


P 


C» 


•usrlutine  timetvmido.  id*.  n.  diet,  ii.*k#  kts,  xh> 


cs  •module*  human  facto**  moderator  function* 
c*«rcfi*e>cii;«paj>*/ volume  s.  10  of 
c 

C**PU*TC9EiTHIS  SUBROUTINE  RETURNS  TIM*  TO  COMPLETE  FO* 
C  TIMKSMARED  TACK* 

C 

CMINPUT  PARAMETERS* 


IDO(N)  -  ADDREBSIN0  INFORMATION  FO*  THE  OPERATOR 

IDC<N>  *  ADDRESSING  INFORMATION  FO*  THE  ENVIRONMENT 

ITA*K(NT*>  -  ADDRESS  IN*  INFORMATION  FO*  THE  TACK 

N  -  INDEX  FO*  IDO  AND  IDE 

NT*  -  INDEX  TOA  ITA9K 

D18T <3>  -  NUN INAL  TASK  PARA*«TER* 

(1)  MEAN 

(2)  STANDARD  DEVIATION 

(3)  DISTRIBUTION  TYF*  . 


C 

c 
c 
c 
c 
c 
c 
c 
c 
c 

C ••OUTPUT  PARAMETERS! 

C  XHU)  -  SKILL  CATEGORY  MODERATOR  VALUES 

XH<  1 ) 


C 

c 
c 
c 
c 
c 

Cl  l 

C ••LOCAL  VARIABLES! 


DIFFERENCE  BETWEEN  DERIVED  AND  SA6CLINE 
MEAN 

XM(2>  -  DIFFERED  3E TWEEN  DERIVED  AND  BASELINE 
STANDARD  DEVIATION 
XM<3>  -  DERIVED  DISTRIBUTION  TYPE 


KO  - 


Kt 

NT  - 


C 
C 

c 
c 

L 

c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 

C« •DIMENSION  ARRAYS 

c 

DIMENSION  IDO (N) 

D I  ME  MB I ON  NEO(l) 

DIMENSION  XG(i>.  XTSK(I).  XTSK2(I> 

C 

Ctf DEFINE  LENGTH  CF  THE  OPERATOR  STATE  VECTOR 


NUMBER  OF  OPERATOR  INDEPENDENT  VARIABLE*  USED  IN 
THIS  MODERATOR  FUNCTION 

NUMBER  OF  ENVIRONMENTAL  INDEPENDENT  VARIABLES  USED  IN 
THIS  MODERATOR  FUNCTION 

NUMBER  OF  TASK  INDEPENDENT  VARIABLES  USED  IN 
THIS  MODERATOR  FUNCTION 

NEO (KO)  -  CLEMENT  NUMBERS  OF  VARIABLES  IN  THE  OPERATOR 
STATE  VECTOR 

NCEOCE)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  ENVIRONMENT 
•TATE  VECTOR 

NTS*  (NT)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  TASK  VECTOR 
NT£K2(NT2>  -  WEIGHTS  OF  THE  BK'lL  CATEGORIES  USED  IN  THIS  TASK 
NME  -  NUMBER  OF  MODERATOR  EQUATIONS 

HI V ( I )  -  NUMBER  OF  INDEPENDENT  VARIABLES  IN  MODERATOR 
EQUATION  l 

rtl)  -  riME-TO-CO^LETE  CALCULATED  FROM  MODERATOR  EQUATION  I 


IDC(N).  DI8T (3) •  ITASK (NTS) 

NIVU).  NTBK  ( l  )  •  NTSK2  (  I  )  «  T(I).  XM(3> 
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L 

MM  KO/./ 

BATA  NT/I/ 

DATA  NT2/I/ 

C 

cttocriNE  needed  element  numbers 

c 

BATA  NEO/3/ 

BATA  MTSK/3/ 

C 

CttOEPINB  NEEDED  SKILL  CATEBORV  NUMBERS 
C 

BATA  HTBK2/11/ 

C 

C*«DEFINE  TTE  VECTOR  ELEMWTS 
C  XOU>-TIHK  on  task  in  hours 
C  XTBK<1>-TASK  MODALITY 
C  XTSK2U) -DETECTION  HEIGHT I NO 

c 

C« (RETRIEVE  VALUES  FOR  OFTRATOR  STATE  VECTOR 
,  C 

CALL  BETOVA  (IDO,  N.  MED.  KO.  XO) 

C 

C«*NTBK  CONTAINS  NUMBERS  OF  THE  TASK  SPECIFIC  HUMAN  FACTORS  DATA 
C 

10FT-I 

CALL  OETTSA  (TOFT.  I  TASK.  NTS,  NTSK.  NT,  XTSK) 

C 

CMNT8K2  CONTAINS  NEISHTS  OF  THE  SKILL  CATEGORIES 
C 

I OAT-2 

CALL  BETTSA  (I OFT.  I TASK.  NTS.  NTSK2,  NT2,  XTBK2J 
C 

CSS INITIALIZE  NME.NIV 
C 

NME-O 

NIV(l)-0 

c 

C«»EVALUATE  XM 

CttFERFORNANCE  DECREMENTS  FOR  TIMEBHARED  TASKS  IS  TASK  DEPENDENT 
C((XT8K ( 1 ) —TASK  MODALITY 
CMXT8K2  ( I  >— DETECTION  MEIOHTINO 

IF  : X fSK2 ( X ). EG. 1 1.0. AND. XTSK <1>.E0. 10.0) THEN 
C 

CMAT  LEAST  TWO  VISUAL  DETECTION  TASKS  ARE  BEING  T I  WE  SHARED 
CtJXOU  )-TlME  ON  TA8K  IN  HOURS 
CUtXMIN-TlME  ON  TASK  IN  MINUTES 

CftDATA  FROM  LEVINE.  ET  AL. .  if7i.  PAGE  If  II 

C  I  I 

NME-NME«>1 

N1V<NNE)-1  1  I 

XMIN-XOtD/AO.O  I 

T  <  NME )  — O .  OS  8 +Q .  0 1 1  $  X  M I M-0 . 000 It  Z  M I N  *  1 2 

CttCALL  A88TMH  TO  DERIVE  SKILL  MODERATORS  FOR  TIME  TO  COMPLEX^ 

C  j  I 

CALL  ABSTMH (DIST . NI V, NME. T, XM)  I 

ELSE  1 

C  1 

Ctt THE  TASKS  DO  NOT  INVOLVE  VISUAL  DETECTION 
C 

NME-NME+! 

NIV<NME)-t 
T  <NME) »DIST  <1  > 

C 
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C««CMX  ABLTHH  TO  MAIL*  KILL  KMMTCM  TOR  TIM  TO  COP* 'Ll  T* 

c 

CALL  NKLTW4<0ItT.NIV.NHK.T.XH> 

■HOIK 

ACTUAM 

■NO 


*• 

fee 
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SUBROUTINE  TMCMUK.  IM.  H.  BUT.  ITMK.  MTS,  XM) 

c 

C«  (MODULE  I VU1AH  FACTORS  MODERATOR  FUNCTIONS 
CMAEFERENCElMOFAOS/VOLUFS  S.  10  OF 

c 

CMFURROSSl  THIS  SUSROUTIF*  IWTIMNS  PROSA* ILITY-TO-COMFLET*  MODERATORS 
C  FOR  TRACKING  TASKS 

c 

Cl* INPUT  PARANITtRSl 

C  IOO(N)  -  A00RCSS1NS  IFSORMATION  FOR  TVS  OFSRATOR 

C  IOC  IM)  -  AOOREBS1NO  INFORMATION  FOR  TMC  ENVIRONHEFIT 

C  1  TACK  (NTS)  -  AOORCSCINS  INFORMATION  FOR  TMC  TACK 

C  N  -  INOCX  FOR  IDO  AND  I  DC 

C  NTS  -  INOCX  FOR  IT ASK 

C  D1ST  f 3)  -  NOMINAL  TASK  FRRAPStTERB 

C  (1)  MUM 

C  12)  STANDARD  DEVIATION 

C  (3)  DISTRIBUTION  TYPt 

C 

CuauTFur  faramctcrsi 

C  mill  -  SKILL  CATS  DORY  MODERATOR  VALUES 

C  mil)  •  DIFFCRSNCX  BCTNCCN  OCA  I  VCD  ANO  BABBLINC 

C  MEAN 

C  XHC2)  »  DIFFCRCNCC  BCTNCCN  DCRIVCD  AND  BASELINE 

c  standard  deviation 

C  Ml))  ■  DCRIVCD  DISTRIBUTION  TYPt 

c 

Co  • 

C ••LOCAL  VARIABLE* I 

C  KO  -  NUMOCR  OF  OPERATOR  INOCRCNOCNT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  KE  -  NUMBER  OF  ENVIRONMENTAL  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  HI  -  NUMBER  OF  TASK  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  NECl'KOI  -  CLEMENT  NUNOERS  OF  VARIABLES  IN  THE  OPERATOR 

C  STATE  VECTOR 

C  NESlYtl  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  TVS  ENVIRONMENT 

C  WYATE  VECTOR 

C  NIASKINTI  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  TASK  VECTOR 

C  NME  -  NUMBER  OF  MODERATOR  EQUATIONS 

C  NIVUI  -  NUMBER  gf  independent  variables  in  moderator 

C  equation  i 

C  PHI  -  PROBABILITY  TO  COMPLETE  CALCULATED  PROM  MODERATOR 

C  EQUATION  I 


C* •DIHENS ION  ARRAY* 

c 

DIMENSION  10OIN).  I DC IM)  .  01 ST  13) .  I TASK (NTS) 
DIMENSION  NE0I3).  NIVUI  •  FID,  XHU) 
DIMENSION  IOU) 

c 

CM  DCF  I  ME  LENGTH  OF  THE  OPERATOR  STATE  VECTOR 
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c 

DATA  *0/3/ 

C 

CttOCFXNC  NQ2CD  ELEMENT  NUMBERS 
C 

DATA  NE0/24.40.3/ 

C 

CtfDEFINE  THE  VECTOR  lUMCNTI 
C  XO(I>-OAV9  WITHOUT  SLE^CR 
C  X0(2>-NUrt»CR  V  WEST  REPIODS 
C  XOt3>*TJHE  ON  TASK  IN  HOURS 

c 

CttIHff  FOLLOWING)  IS  A  DUMMY  STATEMENT  FUNCTION  FOR  TINEA 
C  TINEA  IS  A  FffXTBKEA  FUNCTION  WHICH  RETURNS  CURRENT  TIME 
C  IN  MILITANT  CLOCK  FORMAT 
C 

TlHEA<X>«’900.0iX 

c 

CMRETRICVE  VALUES  FOR  ORCRATOR  STATE  VECTOR 
C 

CALL  SCTOVA  <100.  H.  IOEQ.  KO.  X0> 

C 

Ctt INITIALIZE  NME.NIV 
C 

NME-0 

NIV<1>«0 

c 

c ••evaluate  mm 

Cf • XO < 1 > "DAYS  WITHOUT  8LEER 

Ct«OAfA  FROM  FFEIFFER.  S2EQEL.  TAYLOR.  ANO  SHULER.  1979.  RASE  27 
C 

NHE-NME+1 

NIV<NME>*2 

RH-»-49.  035+97. 444tX0<l>*O.010iT!MEA(  1.0) 

R<NME)  ■RM9DXST ( 1 ) 

C 

Ct*XOCJ> •NUMBER  OF  RE3T  RCAIODS 
C*«X0<3> -TIME  ON  TASK  IN  HOURS 

CMDAfU  FROM  SIEGEL.  RFEIFFER.  KORSTEIN.  WILSON.  A NO  QZKARTAN.  1979,  RAGE  93 
C 

NHE-NNE+1 

NIV(NME)-2 

Rrn S . O 72-0. U29t <0 <2>  «0. 034f XO ( 3) 

R<NME>-RMtOIST (I) 

C 

CttOAlA  FROM  SIEGEL.  RLATZER.  ANO  LANTERNAN.  1947,  RASE  13 
C 

HME-NMEM 

NIV<NME>«I 

RH»1 . 4 77-4. 4S3«CXR < -O. OOSiXO «3» »2> 

R4NHS>«RHtDlSTU> 

C 

CtiCALL  RCLPNH  TO  DERIVE  SKILL  MODERATORS  RQR  PROBABILITY  TO  SC  ON  TARGET 
C 

CALL  RELRNHtDlST.MIV.NME.R.  XM) 

999  RETURN 
END 
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Cl 

fluanouriNC  tracthcioo.  ids.  n.  dist.  itabk.  nts.  xh> 

c 

C(  (MODULI  I  HUMAN  FACTOPS  MODCFATOP  FUNCTION* 
CMMEFEMeNCIlMOFADB/VOLUM*  9.  10  OF 

c 

»  ClirjPMOWl  THIS  euSMOUTSM  RETURN*  TIME  DELAY  MODERATOR* 

C  FOR  TRACKING  TASK* 

C 

CM1NPUT  FARAMETER*! 

C  IOO(N)  -  ADDRESSING  INFORMATION  FOR  THE  OPERATOR 

C  IDE  <N>  -  ADDRESS  I  NO  INFORMATION  FOR  THE  ENVIRONMENT 

C  1  (ASK  (NTS)  -  ADDRESSING  INFORMATION  FOR  THE  TASK 

C  N  -  INDEX  FOR  IDO  AND  IDE 

C  NTE  -  INDEX  FOR  ITA6K 

C  OUT  (3)  -  NOMINAL  TASK  FARAP*TERS 

C  (1)  MEAN 

C  <2>  STANDARD  DEVIATION 

C  (3)  DISTRIBUTION  TYPE 

C 

C(  (OUTPUT  PARAMETERS! 

C  (Mill  -  SKILL  CATEGORY  MODERATOR  VALUES 

C  XH XI)  -  DIFFERENCE  BETWEEN  DERIVED  AND  BASELINE 

C  MEAN 

C  KM', 2)  -  DIFFERENCE  BETWEEN  DERIVED  RND  BASELINE 

C  STANDARD  DEVIATION 

C  XM<3>  »  DERIVED  DISTRIBUTION  TYRE 

C 

Cl! 

CMLOCAL  VARIABLES* 

C  *0  -  NUMBER  OF  OPERATOR  INDEPENDENT  VARIABLES  USED  X N 

C  THIS  MODERATOR  FUNCTION 

C  KE  -  NUMBER  OF  ENV I PONMENT AL  IMDEFENDENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  NT  -  HUMBER  OF  TASK  INDEPENDENT  VARIABLES  USED  IN 

C  THIS  MODERATOR  FUNCTION 

C  NEO(FQ)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  OPERATOR 

C  STATE  VECTOR 

C  NEE  (ICE)  “  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  ENVIROMtNT 

C  STATE  VECTOR 

C  NTACK(NT)  -  ELEMENT  NUMBERS  OF  VARIABLES  IN  THE  TASK  VECTOR 

C  NME  -  NUMBER  OF  MODERATOR  EQUATIONS 

C  NIV(I)  -  NUMBER  OF  INDEPENDENT  VARIABLES  IN  MODERATOR 

C  EQUATION  1 

C  T  < I )  -  TIME  DELAY  FROM  MODERATOR  EQUATION  X 

C 

C ••DIMENSION  ARRAYS 

c 

DIMENSION  IDO (N) .  IDtt(N).  DIST<3>.  I TASK (NTS) 

DIMENSION  NtO(l).  NJVU).  T(I).  XH<S) 

DIMENSION  XO(t) 

C 

CMOCFXNK  LENGTH  OF  THR  OPERATOR  STATE  VECTOR 
C 
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DATA  *0/1/ 

C 

Ct  •DEFINE  NEEDED  ELEMENT  NUMBERS 

c 

DATA  NKO/Sa/ 

c 

CMDCP1NE  THE  VECTOR  ELEMENT! 

C  X0<1> -OPERATOR'S  EXPERIENCE 
C 

C ••RETRIEVE  VALUES  FOR  OPERATOR  STATE  VECTOR 
C 

CALL  SET OVA  <!DO.  N.  NEQ.  KO.  XO> 

C 

CtilNX TIALXZE  NME.N1V 
C 

NME-O 

MXV(X)*0 

c 

ct •evaluate  XN 

*  CtiXOU) -OPERATOR'S  EXPERIENCE 

CttDATA  FROM  SHIPLEY.  1979.  PAST  23 
C 

HME-HHE+1 

NIV<NME>-1 

RH-  (1  •  433-0. 072 JXO  <  1  >  *O.0O3tX0<  1  >  M2)  /  1 000.0 
T <NME>  — RM*OXBT  < 1  * 

C 

COCALL  RELTMH  TO  DERIVE  SKILL  MODERATORS  FOR  TRACKING  TIME  DELAY 
C 

CALL  RELTMH <D  1ST. N IV. NME.  T.XM) 

999  RETURN 
END 
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C» 

SUBROUTINE  ABSPMH(DIST.NIV.NME.P.XM> 
t 

CMMODULCi  HUMAN  FACTORS  MODERATOR  FUNCTIONS 
Ct IRfcFERENCE l MOP ADS/ VOLUME  5. 10  OF 
C 

C •♦PURPOSE i 1 MIS  SUBROUTINE  CALCULATES  VALUES  FOR  THE  SKILL 
C  MODERATORS  FROM  ABSOLUTE  PR0BAD1UE9 

C 

CM  INPUT  PARAMETERS! 

C  DISKS)  -  NOMINAL  TASK  PARAMETERS 

C  (1)  MEAN 

C  <2>  STANDARD  DEVIATION 

C  <3>  DISTRIBUTION  TYPE 

C  N1VU)  -  NUMSER  OF  INDEPENDENT  VARIABLES  IN  MODERATOR 

C  EQUATION  1 

C  NME  -  NUMBER  OF  MODERATOR  EQUATIONS 

C  P<1)  -  PROBABILITY  CALCULATED  FROM 

C  MODERATOR  EQUATION  1 

C 

L'MOUTPUT  PARAMETERS* 

C  XMU>  -  SKILL  CATEGORY  MODERATOR  VALUES 

C  XM(1>  -  DIFFERENCE  BETWEEN  DERIVED  AND  BASELINE 

C  MEAN 

C  XM  <2>  -  DIFFERENCE  BETWEEN  DERIVED  AND  BASELINE 

C  STANDARD  DEVIATION 

C  XM (3)  •  DERIVED  DISTRIBUTION  TYPE 

C 

C?i 

CMLOLAL  VARIABLES! 

C  DP  -  DERIVED  PROBABILITY 

C  TNIV  -  TOTAL  NUMBER  OF  INDEPENDENT  VAR 1 BLEB 

C 

Cl f DIMENSION  ARRAYS 
C 

DIMENSION  DIST (3> .NIV<30) ,P(50) . XM<3> 

C 

CM1N) 1 IAL1ZE  DP  AND  TNIV  TO  ZERO 
C 

DP-0.0 

TNIV-0.0 

c 

CM TITE  DERIVED  PROBABILITY  IS  THE  AVERAGE  OF  THE  PU)S 
C  WEIGH t ED  BY  THE  NIVU)S 
C 

DU  I  I-l.NME 

DP-DPKP(I>INIV<1>  ) 

TNIV— TNI V+N IV  ID 
1  CONTINUE 
DP-DP/TNIV 
C 

CM  IF  THE  DERIVED  PROBABILITY  IS  NEGATIVE. 

c  make  TTe  final  probability  o.o 
c 

IF  »PP.I  1.A,o>lieN 


R-102 


JOlt’;— Dltfl  ill 
ELK 
C 

CM  IF  1HE  DERIVED  PROBABILITY  EXCEEDS  1.0. 
C  MAKE  THE  FINAL  PROBABILITY  1.0 

C 

IF  IDP. ST. 1.0) THEN 
KHU1-1-DISTI11 
ELSE 
C 

CMC  THERM  I SE.  MAKE  THE  FINAL  PROBABILITY 
C  EQUAL  THE  DERIVED  PROBABILITY 
C 

XM<1)-DP-DIBT (!) 

END  IF 
END  IF 


cmassign  values  for  kmc  and  xhtsi 
c 

2  KMO-O.O 
XM(3)»D1SI (3) 

C 

CM I HE  FOLLOWING  PRINT  STATEMENTS  HAVE  BEEN 
C  INSERTED  TO  AID  IN  DEBUGGING  THE  MODERATOR 
C  SUBROUT  1 NEB 
C 


DO  looo  1-1.  NME 

WRITE  (6. 1001)1. PIl).NIV(l) 

lUOl  FORHrtl  </'  THE  PROBABILITY  DERIVED  FROM  MODERATOR  EQUATION  » 
■•IS.'  -  *  •  F5.  3/ '  .  THE  NUMbER  OF  INDEPENDENT  VARIABLES  WAS 
♦  13) 

lOOO  CONTINUE 

RETURN  .  . 

END  7 


! 
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Cl 

SUBROUTINE  ABSTMH (DIST.  N1 V.  NM£,  1 .  XH„k 
C 

C # • MODULE 1 ,4UMAN  FACTORS  MODERATOR  FUNCTIONS 
CMREFERENCE i MOPADS/ VOLUME  3.10  DF 
L 

C* •PURPOSE I  THIS  SUBROUTINE  CALCULATES  VALUES  FOR  THE  SKILL 
U  MODERATORS  FROM  ABSOLUTE  T IME-TO-COMPLETE 

C 

CM  INPUT  PARAMETERS! 

C  DISM3)  -  NOMINAL  TASK  PARAMETERS 

C  <1>  MEAN 

C  (2)  STANDARD  DEVIATION 

C  C3>  DISTRIBUTION  T YPC 

C  N1VII)  -  NUMBER  OF  INDEPENDENT  VARIABLES  IN  MODERATOR 

C  EQUATION  1 

C  NME  -  NUMBER  OF  MODERATOR  EQUATIONS 

L  I<1>  -  11ME-T0-C0MPLE1E  CALCULATED  FROM 

L  MODERATOR  EQUATION  I 

C 

CMOUTPUT  PARAMETERS* 

L  XM(II  -  SKILL  CATEGORY  MODERATOR  VALUES 

C  KM ( 1 )  •  DIFFERENCE  BETWEEN  DERIVED  AND  BASELINE 

C  MEAN 

C  XM(2)  -  DIFFERENCE  BETWEEN  DERIVED  AND  BASELINE 

C  STANDARD  DEVIATION 

C  XMt3>  •  DERIVED  DZS1  RIBL* T ION  TYPE 

C 

Lit 

CMLOLAL  VARIABLES* 

C  01  -  DERIVED  TIME -TO- COMPLETE 

C  UI1V  -  TOTAL  NUMBER  OF  INDEPENDENT  VAR I BLEB 

C 

CM  DIMENSION  ARRAYS 
C 

DIMENSION  DIST (3> .NIV(SO) . 1 (30>.Xh<3> 

C 

CM  JN1 1 1ALIZE  DT  AND  TN1V  70  ZERO 
C 

Dl-0.0 

TMIV-Q.O 

C 

CM  THE  DERIVED  T 1  ME- 1 0- COMPLETE  IS  THE  AVERAGE  OF  THE  T(I)8 
C  WEIGHTED  BY  THE  N1VUJS 
C 

DO  t  I  •  I .  NME 

D1»Df «  U  <I>  tNlV(I)  ) 

TNI  V"  1  Nl  V+NI V  ( I ) 

1  CONTINUE 
DI-DI/1NIV 
C 

CM  IF  1  HE  DERIVED  TIME-TO-COMPLETE  19  NEGATIVE. 

C  MAKE  THE  FINAL  TIME-TO-COMPLETE  0.1 
C 

IF  'PI ,1  1.0.0* THEN 


fi*r. 


fS-Nj 


m 

L*  *  * 

i  * 


V  %' 
S’ 

s-’%* 

\\0 

» •  • 
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SUBROUf  I  HE  RELPMH(DIST.NIV.NME.P.KM) 
t 

IT*  •MODULE*  HUMAN  FACTORS  MODERATOR  FUNCTIONS 
C •♦REFERENCE i MOP ADS/ VOLUME  S. 10  DF 
C 

C • • PURPOSE i 1 H I S  SUBROUTINE  CALCULATES  VALUES  FOR  THE  SKILL 
C  MODERATORS  FROM  ABSOLUTE  PR0BAB11 1EB 

C 

LMINHJI  PARAMETERS* 

C  DISKS)  -  NOMINAL  TASK  PARAMETERS 

C  (1)  MEAN 

L  (2)  STANDARD  DEVIATION 

C  (3)  D1STRIBUT ION  TYPE 

C  N1VMI)  -  NUMBER  OF  INDEPENDENT  VARIABLES  IN  MODERATOR 

C  EOUaI ION  I 

C  NME  -  NUMBER  Of  MODERATOR  EQUATIONS 

L  PU)  *  PROBABILITY  CALCULATED  FROM 

C  MODERATOR  EQUATION  I 

C 

LMUUIPUI  PARAMETERS! 

C  KHll)  -  SKILL  CATEGORY  MODERATOR  VALUES 

C  XM<1>  •  DIFFERENCE  BETWEEN  DERIVED  AND  BASELINE 

C  MEAN 

C  Xh<2)  -  DIFFERENCE  BETWEEN  DERIVED  AND  BASELINE 

L  STANDARD  DEVI A I  ION 

L  XM(3>  -  DERIVED  DISTRIBUTION  TYPE 

C 

Cl  i 

LMLOLaL  VARIABLES* 

L  DP  -  DERIVED  PROBABILITY 

C  P 

•DIMENSION  ARRAYS 
C 

DIMENSION  DIS! (3) ,NIV(50) .P (50) . XM(3> 

C 

C!  •  1H1 1  1/U.I  2E  DP  TO  ZERO 
C 

DP-O.O 

C 

LM1HE  DERIVED  PROBABILITY  IS  A  WEIGHTED  AVERAGE  OF 
C  THE  INDIVIDUAL  P(I)S  BASED  UPON  THE  CONCEPT  OF 
C  DIMINISHING  RETURNS 


DO  1  1-1. NME 

DP-DP  «  (PU)-DIBI  (1)  J/l 
1  CONTINUE 

DP-D1S I  ( 1  >  •*  DP 
L 

L* •  ♦  I F  THE  DERIVED  PROBABILITY  IS  NEGATIVE. 
C  HAKE  THE  FINAL  PROBABILITY  0.0 
C 

IF  (DP. LI. 0.0) THEN 
XM ( I ) — - DIST (1) 

ELSE 

C 


»  " 
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C  nt*l  i he  finml  frodhoili it  i.u 

If  IDH.G1.  .  .0) THEN 
XHIlfM-DIST  111 

else 

c 

CM0IHERH1BC.  HWE  THE  FINHL  PR0BADILI1V 
C  EOUAL  1  HE  DERIVED  f»RO£t«*  1 L I T Y 

C 

XMIII»DR-DIS1  111 
END1F 
CUD  IF 
C 

LMftSSlbN  VllLUES  FClH  XHI2I  UNO  XHt3> 

J  M1uM«u.O 
»H(3)-DI9t  <3) 

C 

Rk I  URN 
INV 


SUBROUTINE  RELTHHIDIBt.NIV.WE.T.XH) 

c 

L»»MOOULE!lfUNAN  FACTORS  MODERATOR  FUNCTIONS 
CMPEFERENCElMORADS/VULUME  S.  JO  OF 
C 

(.••HJPt-'OEEl  1HIS  SUBROUTINE  CALCULATES  VALUES  FOR  THE  SKILL 
L  HCJDEKA t ORS  FROM  ABSOLUTE  TIMES  , 

c 

CFFJM’UI  PARAMETERS) 


I 


I 


01S1  (3)  -  NOMINAL  TASK  PARAMETERS 
(1)  MEAN 

12)  STANDARD  DEVIATION 
<3>  DISTRIBUTOR  TYPE 

N1V(1)  -  NUMBER  OF  INDEPENDENT  VARIABLES  IN  MOt*RATOR 
EUUAI  ION  1 

NFC  -  NUMBER  OF  MODERATOR  EQUATIONS 
III)  -  PROBABILITY  CALCULATED  FROM 
MODERATOR  EQUATION  I 


C 

c 

L 

c 

L 
L 
L 
C 
C 
C 

CMOUIPU1  PARAMETERS! 

C  «M<1 )  -  SKILL  CATEGORY  MODERATOR  VALUES 

L  AMU)  -  DIFFERENCE  BETWEEN  DERIVED  AND  BASELINE 

C  MEAN 

C  XH<2>  -  DIFFERENCE  BETWEEN  DERIVED  AND  BASELINE 

L  STANDARD  DEVIATION 

C  ANTS!  -  DERIVED  DISTRIBUTION  TYPE 

C 

LI  I 

LFILOLAL  VARIABLES! 

C  Df  -  DERIVED  TIME 

C 

C ••DIMENSION  ARRAYS  . 

t  ' 

DIMENSION  DISKS)  .NIVISOT.T  (SO).  XHI3! 

C 

C«*1!U  I IALIZC  DT  TO  ZERO 
C 

D  1-0.0 

c 

CttTHE  DERIVED  TINE  IS  A  NEIOHTED  AVERAGE  OF  I 

C  HE  INDIVIDUAL  KDB  BASED  UPOM  THE  CONCEPT  OF  I 
C  DIM1HISH1N0  RETURNS  I 

c 

DO  I  l-l.NME 

D1-DT  ♦  IT  TI) -DIRT ( I > ) /I 
1  CONTINUE 

DI-DIST  U>  *  DT 
C 

L**1F  THE  DERIVED  TIME  IB  NEGATIVE. 

C  MAKE  THE  FINAL  TIFC  0.1 
C 

IF  IDT. LT. 0.0! THEN 

AMI 1 >  — -D13T II)  *  0.1 

ELSE 

C 
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citotmerhise.  swi  ih t  final  uhe 

C  EQUAL  THE  DERIVED  TIME 

c 

imicm-DiTm) 

END  IF 
C 

CdAISIBN  VALUES  FOS  XNI2)  AKD  XH<3> 

c 

2  XM(2>“U.O 
XM<3>*D1ST (3> 

C 

RETURN 

END 
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VI 


USER  INSTRUCTIONS 


This  auction  con'alna  Instructions  on  writing  ths 
utility  subprograms  GETOVA,  G5TEVA,  GETTSA,  and  TINEA. 
In  addition,  it  also  explain*  how  to  call  ths  moderator 
functions. 


SUBROUTINE  GETOVA  (IDO.  N.  NEO.  KO.  X0> 


IDO(N)  -  An  N-diaenalonal  vector  of  address  information 
for  ths  operator  stats  vector.  IDO  has 
meaning  with  respect  to  the  data  structure 
created  by  the  module  to  store  tha 
operator  state  vector.  For  example,  if  the 
operators  are  numbered  1.2.3....;  then  ID0(1) 
could  equal  the  operator  number.  In  MOPADS. 
IDO  defines  the  data  base  address  of  the 
operator . 

NEO(KO)  -NEO  specifies  the  Indexes  of  elements  of  the 
operator  atate  vector  being  requesvad.  For 
example,  if  X0«2.  NE0(l>-6,  and  NE0(2>>12. 
then  elements  6  end  12  of  the  operator  atate 
vector  are  requested.  Sae  Table  VI-1  for 
tha  definition  of  these  elements. 

XO(KO)  -  GETOVA  returns  the  values  of  the  elements 
specified  in  NEO  in  this  vector.  For  the 
example  above,  if  element  #6  la  24.22  and 
element  #12  is  1.6.  then  XO(l>  would  equal 
24.22  and  X0<2>  would  equal  1.6. 


SUBROUTINE  GETEVA  (IDE.  N.  NEE.  KE.  XE> 


IDE(N)  -  An  N-diaenaienal  vector  of  address  Information 
for  the  environmental  state  vector.  It  is 
analogous  to  IDO  in  GETEVA. 
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T«blc*  VI-1 

OPERATOR  STATE  VECTOR  VARIABLES 


1.  Cor*  temperature  (degree*  C> 

2.  Clo  valu*  of  operator'*  cloth** 

3.  Tlaa  *p*nt  on  task  today  (houra) 

4.  Conaacutiva  daya  of  duty 

9.  Nuabar  of  diaanaiona  on  which  object*  can  ba 
diacriainatad 

6.  Nuabar  of  fir*  unita  for  which  tha  operator  ia 
raaponaibla 

7.  Parcantaga  recovery  ainca  laat  work  period 

8.  Houra  workad  in  tha  pravioua  work  aaaaion 

9.  Houra  batwaan  pravioua  and  currant  work  aaaaion 

10.  Flaah  intenaity  in  foot-laabart  aaconda 

11.  Target  apaad  in  knota 

12.  Target  type  (aaa  laat  page  of  table  for 
daf initiona) 

13.  Target  aiza  <d*t*r*in*d  by  targat  type) 

14.  Targat  color  (white-1,  tan-2,  gre*n-3, 
blu**4,  r*d-9,  y«llow«6) 

15.  Saarch  area  (dograea) 

16.  Uaa  of  binoculara  (1-yea,  0-no) 

17.  Slant  rang*  to  targat  in  n.  ai. 

18.  Targat  Trajectory  (dagraaa  relative  to  north) 

19.  Targat  background  complexity  (low-1,  aediua-2, 
high-3) 

20.  Nuabar  of  diaplay  background  charactara 

21.  Nuabar  of  aaaaagaa  requiring  operator  attention 

22.  Signal*  par  ainuta 

23.  Houra  workad  par  weak 

24.  Daya  without  alaap 

29.  Conaacutiva  daya  of  night  duty 

26.  Nuabar  of  taaka  performed  at  once 

27.  Target /background  contraat  ratio 

28.  Avarag*  houra  alaap  received  par  night  over  3  day 
period 

29.  Objective  function  (not  uaad  by  aodaratora) 

30.  Nuabar  of  goala  conaidarad  (not  uaad  by 
aodaratora) 

31.  Targat  brightncaa  in  foot  leab«rta 

32.  Nuabar  of  conaacutiva  nlghta  with  known  hour* 

alaap 
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Table  VI -1  < continued) 


33.  Sky/ground  ratio  in  foot  laabarta 

34.  Aircraxt  altltuda  in  foot 

33.  Hetaorological  ranga  (viaibility)  in  n.  mi. 

36.  Thraahold  of  oparator 'a  obj act /background  contraat 
ratio 

37.  Targat  haight  in  faat 

38.  Targat  width  in  faat 

39.  Targat  dapth  in  faat 

40.  Horizontal  ranga  to  targat  (n.  ailaa) 

41.  Nuabar  of  raaolution  alaaanta  to  raaolva  tha  targat 

42.  Nuabar  of  araaa  with  suapactad  targata 

43.  Targat  apaad  < knots) 

44.  Fiald  of  viaw  oparator  ia  aaarching  (dagraaa) 

43.  Obaarvar  of faat  (nautical  ailaa) 

46 .  Unuaad 

47.  Diaplay  targat  location  (dafinad  by  a  3x3  matrix 
nuabarad  frca  laft  to  right,  than  down) 

48.  Targat  diapJacaaant  froa  obaarvar  in  dagraaa  (left- 
nagativa,  right»poaitiva) 

49.  Diaplay  raaolution  in  nuabar  of  linaa 

50.  Avaraga  haight  of  nontargata  in  vlaw  in  faat 

31.  Avaraga  width  of  nontargata  in  viaw  ir.  faat 

32.  Avaraga  dapth  of  nontargata  in  viaw  in  faat 
S3.  Diatanca  to  diaplay  in  faat 

34.  Diaplay  haight  in  faat 
S3.  Diaplay  width  in  faat 

36.  Targat  noiaa  laval  in  dB 

37.  Targat  duration  in  ainutaa 

38.  Nuabar  of  tlaaa  tha  oparator  haa  parforaad  thia 
taak  bafora) 

39.  Signal  probability 

60.  Nuabar  of  raat  parioda  par  work  ahift 

61.  Taak  arror  factor  (not  uaad  in  aodarator 
aubroutinaa) 

62.  Taak  alaaant  arror  factor  (not  uaad  in  aodarator 
aubroutinaa) 

63.  Daya  ainca  tha  taak  waa  laat  practiced 

64.  Oparator'a  aanaa  of  direction  (good*l,  poor*0> 

65.  Skin  taaparatura  (dagraaa  cantigrada) 

66.  Hinutaa  in  currant  aabiant  taaparatura 

67.  Pravioua  akin  taaparatura  prior  to  changing 
anvironaanta 
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Table  VI-1  (continued) 
TARGET  TYPE  CODES 


CODE  NO. 


HAKE 


COUNTRY 


1 

F4C 

USA 

2 

F100 

USA 

3 

T33 

USA 

4 

OTHER  JET 

5 

U1A 

USA 

4 

U4A 

USA 

7 

OTHER  PROP 

8 

01A 

USA 

f 

0H23 

USA 

10 

OTHER  HELICOPTER 

It 

TAMN 

12 

JEEP 

13 

TROOP 

14 

APC 

IS 

TRUCN 

14 

ZERO 

17 

halftrack 

18 

F14 

USA 

19 

FIS 

USA 

20 

F14 

USA 

21 

FIG 

USA 

22 

HI821 

USSR 

23 

M1623 

USSR 

24 

Ml  625 

USSR 

25 

SOLBIER(FOOT) 

ANY 

24 

MIG-27 

USSR 

27 

81M7 

USSR 

28 

QIAN8  Ji-S 

PRC 

29 

30 

31 

32 

33 

34 

35 
34 

37 

38 
30 

40 

41 


R-23S8 
MIRAGE  3E 
MIRAGE  Ft 
HIRA6E  2090 
MIRAGE  4000 
MIRA6E  4 
MIRAGE  5 
MIRA6E  50 
AU.440 
498 

HS748  ■ 

MS. 780 
P.1099 


FRANCE 

FRANCE 

FRANCE 

FRANCE 

FRANCE 

FRANCE 

FRANCE 

FRANCE 

GREAT  BRITAIN 
GREAT  BRITAIN 
GREAT  BRITAIN 
GREAT  BRITAIN 
GREAT  BRITAIN 


MISSION 


6round  Attack 

Military  eurvaillanco 

Fighter 

Fighter 

Fighter 

Fighter 

Bonber 

Ground  Support 
Fighter 

Nilitery  Traneport 
Bonber 

Military  Traneport 
Military  Transport 
Ground  Attack 


Table  VI “1  < continued) 


42 

IAI202  IS3AEL 

Military  Transport 

43 

MIRAGE  3C  ISRAEL 

Fightar 

44 

XfirC2 

!  ISRAEL 

Fightar 

43 

6.222 

ITALY 

Military  Transport 

44 

FI  043 

ITALY 

latarcaptor 

47 

MI.326K  ITALY 

Strika 

48 

S.H.1019E  HALT 

Military  STOL 

49 

F-1 

JAPAN 

Fightar 

30 

C.207A 

i  SPAIN 

Military  Transport 

31 

SF-5A 

SPAIN 

Fightar 

32 

HA-220 

>  SPAIN 

6routtd  Attack 

S3 

33X8 

8UEBEN 

Ground  Attack 

34 

JA37  i 

SUEDEN 

Fightar 

S3 

J-1  j 

|  ,  YUGOSLAVIA 

Strika 

*  34 

Light  | 

(t. 9. blinking} 

37 

Digit 

(digit  on  a  display) 

38 

HIB-17 

USSR 

30 

mib-19 

USSR 

40 

SU-7 

USSR 

41 

SU-9PM 

USSR 

42 

SU-11 

USSR 

43 

SU-15 

USSR 

44 

SU-19 

USSR 

43 

8U-20 

USSR 

44 

YAI-28P  USSR 

47 

YAK-34 

USSR 

48 

TU-28P 

USSR 

49 

1L-28 

'  USSR 

70 

M-4 

USSR 

71 

TU-14 

USSR 

72 

TU-20 

USSR 

73 

TU-22, 

USSR 

74 

TU-24, 

USSR 

73 

IL-38 

USSR 

74 

TU-124 

USSR 

77 

HI 6-1 S 

USSR 

78 

L-29 

USSR 

79 

L-39 

USSR 

80 

J-3 

USSR 

81 

J-4 

USSR 

82 

J-7 

USSR 

83 

J-8 

USSR 

84 

H-3 

USSR 

83 

H-4 

USSR  , 

84 

CJ-4 

USSR 

87 

Y-11 

USSR 

88 

MIRAGE 

111  FRANCE 

_ _ _ — 
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NEE(KE)  -  Element  numbers  of  the  environmental  atata 

vactor.  Thia  la  analogoua  to  WEO  in  GETOVA. 
For  a  list  of  tha  environmental  atata  vactor, 
aaa  Tabla  VI -2. 

XE(KE)  -  GETEVA  raturna  tha  values  specified  by  NEE  in 
XE.  XE  la  analogouc  to  XO  in  GETOVA. 


SUBROUTINE  GETTSA  (IOPT,  ITASK.  NTS,  NTSK,  NT,  XTSK> 


IOPT  -  Option 

0  -  Requesting  task  tlaa  inforaation 

1  -  Raquaating  task  vactor  inforaation 

2  -  Raquaating  akilla  inforaation 

3  -  Raquaating  ayataa  raaourca  inforaation 

ITASK  -  An  NTS  dimensional  vactor  of  addraaa 

inforaation  for  tha  task  data.  It  la  analogoua 

to  IDO  in  GETOVA. 

NTSK (NT)  -  Tha  deairad  e lament  nuabara.  Thera  are  four 

caaea: 

I0PT"»0  -  NTSK  is  not  uaed 
IOPT»l  -  NTSK  contains  element  nuabara  of 
tha  task  specific  categories 
I0PT*2  -  NTSK  contains  skill  nuabara 
I0PT*3  -  NTSK  contains  resource  numbers 

XTSK(NT)  -  The  values  of  variables  requested  in  NTSK 
above.  There  are  four  cases: 

I0PT-0  -  XTSK<1)  to  XTSK (3)  are  distribution 
type,  mean,  and  standard  deviation. 
I0PT«1  -  Tha  values  of  the  task  vector 
elements  requested  in  NTSK. 

I0PT«2  -  Tha  weights  of  the  skill  categories 
specified  by  tha  location  in  the 
vactor  (e.g.,  XTSKC5)  would  be  tha 
weight  for  skill  number  5. 

10PT*3  -  Tha  values  of  resource  parameters 
specified  in  NTSK. 
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Table  VI-2 


ENVIRONMENTAL  STATE  VECTOR  VARIABLES 


X.  Dry  bulb  temperature  In  degrees  centigrade 

2.  Relative  hualdlty 

3.  Air  aoveaent  rate  (aliea/hour) 

4.  Nolae  level  In  dB 

5.  Work  area  illumination  in  foot-laaberta 

6.  Number  of  c peratora  on  duty 

7.  Vibration  aa  defined  by  vertical  movement  in  Hz 

8.  Ambient  vapor  praaaure  in  mb 

9.  Noiae  predictability  (consistant»0,  inconsistent >1 ) 


Table  VI-3  contalna  definitions  of  the  date  in  the  task 
vector.  Resource  requireaente  ere  not  used  in  the 
current  NOPADS  implementation  and,  therefore,  are  not 
utilized  by  the  aoderator  functions.  However,  we  felt 
that  this  option  wee  iaportent  for  growth. 


FUNCTION  TINEA O 


TINEA  returns  the  current  ailltary  tiaa  accurate 
to  the  nearest  ainute.  TINEA  ranges  in  value  froa 
0000  to  2359.  TINEA  is  a  REAL  function. 


All  of  the  aoderator  functions  have  the  following 
calling  sequence: 

SUBROUTINE  xxxxxxH  <ID0,  IDE,  N,  DIST,  ITASK, 

NTS,  XN) 

The  paraaeters  in  this  calling  sequence  are  defined  as 
follows: 

IDO(N) ,  IDE (N)  -  Addressing  inforastion  for  the 
operator  and  environmental  state 
vectors,  respectively.  These  vectors 
are  then  used  to  call  GETOVA  and 
GETEVA. 

DIST<3>  -  Nominal  (i.e.,  baseline)  task 
paraaeters . 

DIST<1) ■mean 

DIST (2) ^standard  deviation 

DIST<3) ■distribution  type  (see 
Table  VI-4) 

ITASK (NTS)  -  Addressing  information  for  the 
task.  ITASK  is  used  for  calling 
GETTSA. 


Table  VI-3 


TASK  VECTOR  VARIABLES 


1. 

2. 

3. 

4. 

5. 

6. 


7. 

8. 
9. 
10 
11 


Kcal /minute  required  by  the  taak 

Number  of  tasks  which  might  ba  performed  after  this 
ona 

Primary  atimulus  moda 
Sacondery  atimulus  moda 
Raaponaa  moda 

Obaarvar/targat  position  <1*  ground  to  ground, 

2«  air  to  ground, 

3s  ground  to  air, 

4"  air  to  air, 

5*  at  a  display 


Diatanca  to  control  in  fact 
Control  width  in  fart 

Number  of  displays  that  must  be  monitored 
.  Number  of  controls  that  might  be  actuated 
.  Number  of  items  which  must  be  kept  in  ahort  term 

memory 


Tablo  VI-3  (continued) 


TASK  SPECIFIC  DATA 


SlIEliCliSB 


filLwll 


Kilocalories/ninute 
Nunber  of  broncho*  out 
Stimulus  Moot  1 
A  two-digit  nunbtr 

10'*  digit  -  0  -  no  visual 
1  -  visual 

t's  digit  -  0  -  co  auditory 
1  -  auditory 

Stimulus  Node  2 
A  throe-digit  nunber  at  above 
100'*  digit-  0  -  bo  olfactory 
1  -  olfactory 

10'*  digit  -  0  -  bo  kinesthetic 
1  -  kinesthetic 

1't  digit  -  0  -  no  tactile 
1  -  tactile 

Response  Mode 
A  tvo-digit  aunbor 

10'*  digit  -  0  -  bo  vocal 
1  -  vocal 

1's  digit  -  0  -  no  tactile 
1  -  tactile 
Observer  -  Target  Position 

1  -  ground  to  ground 

2  -  air  to  ground 

3  -  ground  to  air 

4  -  air  to  air 

5  -  at  a  display 

Control  Distance  (distance  fron  operator 
to  control  device  in  feet) 


1 

1 

10 


00 


1 


3 


1 


Control  Width  (width  of  the  control  0.1 

device  in  feet) 


Nunber  of  Displays  1 

Nunber  of  Alternatives  (nunber  of  possible  1 
controls  that  nay  need  to  be  actuated 
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Tftblo  VI -4 


DISTRIBUTION  TYPES 


CONSTANT 

NORMAL 

UNIFORM 

ERLANG-1  (cxponvntial ) 

LOGNORMAL 

NOT  USED 


XM<3)  -  Hodaratad  output 

XM<1) "Chang*  to  tha  noalnal  aaan.  In  othar 
words ,  tha  aodaratad  sa«n  la 
DIST (1) +XH (1 ) 

XM <2>"Changa  to  tha  noalnal  standard  daviation 
XMO>-Naw  distribution  typ* 


As  santlonad  previously,  in  tha  currant  KOPADS 
iaplaaantatlen,  XH(2)»0  and  XH(3>«DXST(3> .  Only  tha 
aaan  is  currantly  aodaratad. 
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VIII 


COMMON  VARIABLE  DEFINITIONS 


No  coamon  varlablaa  ira  uaad  by  thaaa  aubroutinea. 
All  variaolaa  ara  paaaad  aa  aubroutina  paraaatara  or 
ara  local  varlablaa. 
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1-0  Standard  MOPADS  Terminology 

1 

' 

AIR  DEFENSE  SYSTEM  A  ccmpor- 

nt  of  Air  Defense  vhich  includes 

equipment  and  operators  and  for  vhich  techni¬ 
cal  and  •Lactical  training  are  required. 
Examples  are  IEAWK  and  the  AN/TSQ-73. 


AIR  DEFENSE  SYSTEM  Models  of  operator  actions  and  equipment 
MODULE  characteristics  for  Air  Defense  Systems  in 

the  MOPADS  software.  These  models  are  pre¬ 
pared  with  the  SAINT  simulation  language. 

Air  Defense  System  Modules  include  the  SAINT 
,  model  and  all  data  needed  to  completely 

define  task  element  time,  ta3k  sequencing 
I  requirements,  and  human  factors  influences. 


Alrf  SCENARIO  a  spatial  and  temporal  record  of  aerial 

activities  and  characteristics  of  an  air 
defense  battle.  The  Air  Scenario  includes 
aircraft  tracks,  safe  corridors,  ECK,  and 
other  aircraft  and  airspace  data.  See  also 
Tactical  Scenario. 


BRANCHING 

* 

A  term  used  in  the  SAINT  simulation  language 
to  mean  the  process  by  which  TASK  nodes  are 
sequenced.  At  the  completion  of  the  simulated 
activity  at  a  TASK  node,  the  Branching  from 
that  node  determines  which  TASK  nodes  will  be 
simulated  next. 

DATA  BASE  CONTROL 
SYSTEM 

i 

1  , 

That  part  of  the  MOPADS  software  which  performs 
all  direct  communication  with  the  MOPADS  Data 
Base.  All  information  transfer  to  and  from 
the  data  base  is  performed  by  invoking  the  sub¬ 
programs  which  make  up  the  Data  Base  Control 
System. 

DATA  SOURCE 
SPECIALIST 

A  specialist  in  obtaining  and  interpreting 

Army  documentation  and  other  data  needed  to 
prepare  Air  Defense  System  Modules. 

An  element  of  an  Environmental  State  Vector. 
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ENVIRONMENTAL 
STATE  VARIABLE 


i 


ENVIRONMENTAL 

STATE  VECTOR 

An  array  of  values  representing  conditions  or 
characteristics  that  may  affect  more  tnan  one 
operator.  Elements  jf  Environmental  State 
Vectors  may  change  dynamically  during  a  MOPADS 
simulation  to  represent  changes  in  the  environ¬ 
ment  conditions. 

MODERATOR  FUNCTION 

A  mathematical/logical  relationship  which 
alters  the  nominal  time  to  perform  an  operator 
activity  (usually  a  Task  Element).  The  nominal 
time  is  changed  to  represent  the  operator's 
capability  to  perform  the  activity  based  on  the 
Operator's  State  Vector. 

MOPADS  DATA  BASE 

A  computerized  data  base  designed  specifically 
to  support  the  MOPADS  software.  The  MOPADS 

Data  Base  contains  Simulation  Data  Set(s).  It 
communicates  interactively  with  MOPADS  Users 
during  pre-  and  post-run  data  specification  and 
dynamically  with  the  SAIHT  software  during 
simulation. 

MOPADS  MODELER 

An  analyst  who  will  develop  Air  Defense  System 
Modules  and  modify/develop  the  MOPADS  software 
system. 

MOPADS  USER 

An  analyst  who  will  design  and  conduct  simu¬ 
lation  experiments  with  the  MOPADS  software. 

MSAINT(MOPADS/SAINT) 

The  variant  of  SAUTT  used  in  the  MOPADS  system. 
The  standard  version  of  SAIHT  has  been  modified 
for  MOPADS  to  permit  shareable  subnetworks  and 
more  sophisticated  interrupts.  The  terms  SAIHT 
and  MSAIHT  are  used  interchangeably  when  no 
confusion  will  result.  See  also,  SAIHT. 

OPERATOR  STATE 
VARIABLE 

One  element  of  an  Operator  State  Vector. 

OPERATOR  STATE 

VECTOR 

An  array  of  values  representing  the  condition 
and  characteristics  of  an  operator  of  an  Air 
Defense  System.  Many  values  of  the  Operator 
State  Vector  will  change  dynamically  during 
the  course  of  &  MOPADS  simulation  to  represent 
changes  in  operator  condition. 
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OPERATOR  TASK 


An  operator  activity  identifies  during 
weapons  system  front-end  analyses. 


SAINT 

The  underlying  computer  simulation  language 
used  to  model  Air  Defense  Systems  in  Air 

Defense  System  Modules.  SAINT  is  an  acronym 
for  Systems  Analysis  of  Integrated  Networks  of 

T  as  Its .  It  is  a  veil  documented  language  designed 
specifically  to  represent  human  factors  aspects 
of  man/machine  systems.  See  also  MSAINT. 

SIMULATION  DATA  SET 

The  Tactical  Scenario  plus  all  required  simu¬ 
lation  initialization  and  other  experimental 
data  needed  to  perform  a  MOFADS  simulation. 

SIMULATION  STATE 

At  any  instant  in  time  of  a  MOFADS  simulation 
the  Simulation  State  is  the  set  of  values  of  all 
variables  in  the  MOPADS  software  and  the  MOPADS 
Data  Base. 

SYSTEM  MODULES 

See  Air  Defense  System  Modules. 

TACTICAL  SCENARIO 

The  Air  Scenario  plus  specification  of  critical 
assets  and  the  air  defense  configuration 
(number,  type  and,  location  of  weapons  and  the 
command  and  control  system). 

TACTICAL  SCENARIO 
COMPONENT 

An  element  of  a  Tactical  Scenario,'  e.g.,  if  a 
Tactical  Scenario  contains  several  Q-73's,  each 
one  is  a  Tactical  Scenario  Component.  1 

TASK 

!,  i 

See  Operator  Task. 

i  1 

TASK  ELEMENTS 

Individual  operator  actions  which,  when  grouped 
appropriately,  make  up  operator  tasks.  Task 
elements  are  usually  represented  by  single 

SAINT  TASK  nodes  in  Air  Defense  System  Modules. 
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2-0  Other  Terminology’' 


COMMAND 

A  keyvord  entered  by  the  user  that  specifies 
some  action  to  be  taken.  Commands  mav  be 
abbreviated  to  the  letters  that  will  make 
them  unique  from  all  the  otner  commands. 

COMMAND  MODES 

The  manner  in  which  a  command  may  be  entered: 
either  regular,  concise,  or  command-name- 
only.  In  regular  mode  the  user  will  enter 
the  command  followed  by  a  list  of  prompts  and 
their  responses.  In  concise  mode  the  user 
enters  the  command  followed  by  a  list  of 
responses.  The  command-name-only  mode  is  the 
simplest  to  use  since  the  user  only  enters  the 
command  and  is  then  prompted  for  all  the 
remaining  information. 

COMMAND  SUBROUTINE 

The  subroutine  that  performs  the  logic  of  the 
command  and  processes  responses  to  the 
command’s  prompts. 

DEFAULT  VALUES 

The  value  that  will  be  used  for  a  response. 

A  value  that  is  used  when  the  user  elects 
not  to  explicitly  enter  a  value  for  a 
response. 

ENUMERATED  VALUES 

A  discrete  set  of  allowable  responses  for 
a  prompt. 

LOWER  BOUND/ 

UPPER  BOUND 

The  minimum/maximum  value  for  a  response. 

MIXED  RESPONSE 

A  response  made  up  of  more  than  one  type 
(integer,  real,  or  character). 

PROMPT 

A  keyvord  requiring  a  value  or  string  as  a 
response. 

PROMPT-hESPONSE- 

GROUPS 

The  sets  of  prompts  followed  by  their 
responses . 

RESPONSE 

The  value  entered  for  a  prompt. 

RESPONSE 

GROUPS 

Tue  set  of  responses  for  a  prompt. 

RESPONSE 

TYPE 

The  type  of  a  response:  either  a  real, 
integer,  character  or  mixed. 

RESPONSE 

TYPE 

UNIVERSE 

Specifies  the  characteristics  of  the  values 
for  responses.  The  response  universe  may¬ 
be  a  range  of  values  or  an  enumerated  set. 

UPDATED  DEFAULTS 

Default  values  that  are  overwritten  when  the 
user  explicitly  enters  a  new  value.  The 
new  value  will  become  the  default  value. 

I.  PURPOSE 


1-0  GENERAL  DESCRIPTION  OF  FREE-FORMAT  SYNTAX  PROCESSOR 
(FFSP)  ROUTINES 

this  FORTRAN  7?  program  module  is  used  to  perform  interactive 
1m  syntax  processing  of  MOPADS  user  commands.  This  module 
checks1  each  field  in  the  command  for  both  arithmetic  and  logical 
validity.  The  responses  are  returned  from  the  FFSP  programs  jn 
three  response  output  arrays  (one  for  character  responses,  one  for 
integer  responses,  and  one  for  real  responses).  If  an  error  occurs 
in  the  processing  of  a  command  and/or  its  prompts  and  responses, 
one  of  three  actions  may  occur.  The  user  may  be  asked  to  re-enter 
the  information,  the  command  may  be  cancelled  and  control  returned 
to  the  point  where  the  FFSP  routines  were  called,  or  in  extreme 
cases  execution  will  terminate. 

i 

The  FFSP  module  is  a  generalized  processor  of  the  syntax 
described  below.  It  is  used  by  the  MOPADS  user  interface  to  process 
MOPADS  user  commands.  Since  it  is  a  general  processor,  however,  it 
can  be,  used  to  write  user  interfaces  in  non-MOPADS  contexts. 


I 

2-0  COMMAND  MODES  . 

The  commands  may  be  entered  in  any  one  of  three  forms: 

1.  command-name-only 

2.  regular  mode  (default  mode),  and 

3.  concise  mode. 

The  three  forms  reflect  the  relative  experience  the  user  may  have 
with  a  particular  command.  The  user  that  has  very  little  experience 
with  a  command  may  enter  that  command  in  the  command-name-only  form. 
After  gaining  some  experience  with  a  command  and  its  prompts  the 
user  will  begin  to  enter  the  command  in  regular  mode.  When  the  user 
becomes  proficient  with  a  particular  command  he/she  will  begin  using 
the  command  in  concise  mode.  A  description  of  the  three  command 
forms  follows. 


Comm an d-Name-Onlj 


This  form  is  illustrated  in  Figure  1-1  where  upper  case 
letters  are  typed  by  the  computer  and  lower  case  letter  are  typed 
by  the  user.  The  user  simply  enters  the  command  and  the  system  will 
prompt  the  user  for  any  additional  information  needed  (HAIR [BL0NDE]= 
is  a  prompt). 


ENTER  COMMAND: 


J 


The  information  printed  between  the  brackets  "( . ]" 

following  e.  prompt  represents  the  current  default  values  for  that 
prompt.  If  the  us**r  enters  "DEF”  as  hia  response,  the  value(s)  in 
the  brackets  will  become  the  response  to  the  prompt.  If  the  text 
"NO  DEFAULT"  appears  between  th.  brackets,  the  user  must  enter  a 
response  for  this  prompt  other  than  the  "DEF"  response. 


Figure  1-2  illustrates  the  use  of  this  form.  Once 
again  the  upper  case  letters  represent  information  typed  by  the 
computer  and  lower  case  letters  represent  user  supplied  informa¬ 
tion.  In  each  of  the  examples  in  Figure  1-2  the  user  enters  the 
conmand  followed  by  a  complete  or  partial  list  of  prompts  and 
responses. 


In  the  first  example ,  the  user  entered  the  command  and  the 
entire  list  of  prompts  and  responses.  The  prompt-response  groups 
may  be  entered  in  any  order  and  are  separated  from  one  another  with 
a  slash  (/).  The  next  two  examples  illustrate  the  case  where  the 
user  enters  the  command  followed  by  &  partial  list  of  prompts  and 
responses.  In  the  second  example  in  Figure  1-2  the  last  non-blank 
character  entered  by  the  user  is  a  dash  (-).  The  dash  instructs  the 
system  to  prompt  for  all  unentered  responses.  In  the  third  example, 
no  dash  is  typed  at  the  end  of  the  command  line.  Thi3  instructs  the 
system  to  prompt  only  for  responses  that  have  no  defaults  and  to 
accept  the  default  values  for  all  other  responses. 


2-3-  Concise  Mode. 

This  form  is  illustrated  in  Figure  1-3.  The  user  enters 
the  command  followed  by  a  partial  or  complete  set  of  responses.  The 
response  list  must  he  entered  in  a  preset  order  which  is  the  same 
order  the  prompts  appear  at  the  terminal  when  using  the  cammand-name- 
only  form.  The  user  enters  only  the  responses, with  the  different 
response  groups  separated  by;  slashes. 

The  first  example  in  Figure  1-3  illustrates  the  case  where  the 
user  entered  the  command  followed  by  a  complete  list  of  responses. 

In  this  example,  regular  mode  is  the  default  mode;  therefore,  the 
user  must  precede  any  commands  entered  in  concise  mode  with  a  "C-". 
This  instructs  the  system  that  the  following  command  and  responses 
are  in  concise  mode.  The  dash, at  the  end  of  the  second  example  has 
the  same  effect  ao  in  regular  mode;  the  system  will  prompt  for  any 
unentered  responses.  If  the  user  leaves  off  the  dash,  as  in  the 
last  example,  the  system  will  use  the  default  value(s)  for  any 
unentered  responses  with  default  value(s). 


S-15 
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Figure  1-2.  Examples  of  Commands  In  The  Regular  Mode  Form 


Figure  1-3.  Examples  of  Commands  In  The  Concise  Mode  Form. 


3-0  FFSP  SYNTAX  PULES 


The  following  rules  will  formalize  the  previous  discussion 
of  how  syntax  is  processed  by  FFSP. 

3-1.  The  coiamand-na^e-only  fora  of  a  command  nay  be  used 
in  regular  or  concise  modes  by  typing  only  the  command  name. 

3-2-  Blank  responses  may  be  entered  where  character 
responses  are  required.  To  enter  a  blank  response  type  "  " 

( including  the  quotes ) .  At  least  one  blank  must  be  entered 
between  the  quote  Darks. 

3-3.  A  command  may  be  cancelled  at  any  time  by  typing 
CANC  for  any  prompt  or  response.  You  can  not  use  CANC  as  an 
abbreviation  to  a  prompt . 

3-^.  The  user  may  elect  to  use  the  default  value(s)  by 
typing  DEF  for  any  response  in  a  response  list  up  to  one  field 
past  the  last  response  in  the  list. 

3-5.  Slashes  (/)  must  be  used  to  separate  one  prompt- 
response  group  from  another.  Blanks  or  commas  may  be  used  to 
separate  all  other  fields.  The  equal  sign  should  be  used  to 
separate  prompts  from  their  responses;  however,  it  is  not  required. 

3-6.  Command  and  prompt  names  may  be  abbreviated  to  any 
non-ambiguous  string  of  characters.  For  example,  if  there  were 
two  commands,  DESIGN  and  DESCRIBE,  they  can  1-  abbreviated  DESI  and 
DESC  respectively.  The  commands  may  be  abbreviated  in  longer  forms. 
FGr  example,  the  user  may  enter  DESC,  DESCR,  CESCRI ,  DECCRIB,  or 
DESCRIBE  for  the  command  DESCRIBE. 

3-7-  If  a  command  line  in  regular  or  concise  mode  is  ended 
with  more  than  one  dash,  the  last  dash  will  signify  to  the  system 
to  prompt  the  user  for  all  the  unentered  responses.  Other  dashes 
will  then  be  considered  as  part  of  a  response. 

3-8.  Any  multiple  combination  of  commas  and  blanks  is  tx'eated 
as  a  single  separator.  For  example, 

NAME  =  BILL  WOLF  and  NAME  =  BILL  ,  WOLF 

are  equivalent . 

3-9*  If  the  user  enters  an  incorrect  response  or  misuses 
the  syntax,  FFSP  will  explain  the  error  and  prompt  interactively  for 
all  remaining  responses. 

3-10.  It  is  possible  to  specify  the  default  mode  to  be  regu¬ 
lar  or  concise.  This  defualt  mode  can  be  overridden  for  individual 
commands  by  preceding  the  command  name  with  "R-"  (for  regular  mode) 
or  't-"(for  concise  mode). 


II.  DATA  STRUCTURE 


1- 0  INTRODUCTION 

The  data  structure  ased  by  the  FFSP  programs  may  be  con¬ 
sidered  in  two  parts,  1)  input  data  structure  and  2)  output  data 
structure.  The  input  data  is  passed  to  the  FFSP  subroutines 
through  the  subroutine  parameters  and  contains  the  information 
describing  the  prompts  and  responses.  The  output  data  is  generated 
by  the  FFSP  programs.  It  contains  the  user's  responses  to  the 
prompts. 

2- 0  INRJT  DATA  STRUCTURE 

The  input  data  structure  is  contained  in  arrays  passed  to 
FFSP  as  formal  subprogram  parameters.  The  data  arrays  and  their 
relationships  to  one  another  are  illustrated  in  Figure  II-l.  The 
following  subsections  discuss  their  form  and  contents. 

2-1.  PROMPT (NPMTS)  is  a  CHARACTER  array  used  for  storing  prompt 
names  for  a  command.  The  dimension  of  this  array,  NPMTS,  is  passed 
to  the  FFSP  programs  as  a  formal  parameter.  The  order  that  the 
prompt  names  are  stored  in  PROMPT  will  be  the  order  the  system  will 
print  them  and  accept  their  responses  while  in  the  comand-name- 
only  form. 

2-2.  KPMTS(NPMTS,2)  is  an  INTEGER  array  containing  two  columns. 
There  is  a  correspondence  between  the  rows  of  KPMTS  and  the  elements 
of  the  PROMPT  array.  The  information  in  row  3  of  the  KPMTS  array 
pertains  to  the  third  prompt  in  PROMPT.  Column  1  of  any  row  contains 
a  pointer  to  a  column  of  the  LTAX  array.  Column  2  is  working  storage 
used  internally  by  the  FFSP  programs  to  dynamically  keep  track  of 
which  responses  have  been  entered. 

2-3.  LTAX(5,NTAX)  is  an  INTEGER  array  with  information  per¬ 
taining  to  the  prompts  in  the  PROMPT  array.  The  information  des¬ 
cribes  the  expected  responses  and  points  to  information  stored  in  the 
response  universe  arrays  (RESP,  NRESP,  CRESP).  The  contents  of  a 
column  of  the  LTAX  array  are  as  follows: 


Row 

1 

Response  type  * 

Row 

2 

Response  universe  type 

Row 

3 

Pointer  to  the  response  xmiverse 
array  of  the  type  indicated  by  the 
value  in  Row  1  (RESP, NRESP,  or  CRESP) 

Row  1 

The  number  of  default  values  stored 
in  the  response  universe  array. 

Row 

5 

Number  of  enumerated  values  stored  in 
response  universe  array. 

PROMPT(NPWTS) 


NPMTS-2 

NPMTS-1 


KPMTSfNPMTS) 


CRESP(NC) 

or 

NRESP(NI) 


LTAX($,NTAX) 


N=NR,  NC,  or  NI 

@  - 

Number  of  default  values 

Two  elements  of  response  universe 
array  used  for  storing  upper  and 
lower  bound  values  ' 

©  - 

Number  of  enumerated  values 

Figure  II-l.  Input  D*rta 

Structure. 

Bov  1  indicates  response  type  using  the  values- 
shown  in  Table  II-l.  The  length  of  the  list,  n,  is  also  contained 
in  the  response  type  value.  For  exanple,  the  response  type  value 
for  a  list  of  six  real  values  would  be  2006.  If  the  value  of  n  is 
0,  the  list  is  of  unspecified  length.  The  mixed  response  type 
(values  >1*000  and  <5000)  permits  the  commend  designer  to  allow  for 
responses  of  more  than  one  type.  For  example,  say  the  command 
designer  wants  a  response  to  consist  of  two  character  strings 
followed  by  an  integer  and  another  character  string.  The  value  for 
this  response  type  would  be  1*003.  'i-ia  "3"  indicates  that  the  mixed 
response  consists  of  three  response  type  values.  The  next  three 
columns  of  the  LTAX  array  would  contain  the  information  concerning 
the  response  lists  that  make  up  the  mixed  response  (the  values  3002, 
1001,  and  3001  would  be  in  row  1  of  these  columns).  ISie  mixed  response 
type  can  not  have  an  undefined  length;  therefore,  a  value  of  1*000 
will  always  be  invalid.  In  addition  to  this,  a  mixed  response  list 
can  not  contain  any  response  lists  of  undefined  length  (no  1000, 

2000,  or  3000  responses  type  values  in  a  nixed  response  list) .  Examples 
of  a  mixed  response  prompts  are  given  in  Section  VI. 

Row  2  of  the  LTAX  array  is  a  value  from  Table  II-2.  This 
code  value  represents  the  type  of  response  universe  the  response 
must  be  from.  Values  >100  signify  responses  with  defaults  that  are 
updated  every  time  a  new  entry  is  made  (the  new  response  becomes  the 
current  default  value(s)).  It  is  invalid  to  use  response  universe 
type  values  >100  with  response  lists  of  unspecified  length. 

Row  3  of  the  LTAX  array  has  the  pointer  to  the  response  uni¬ 
verse  array,  RESP,  NRESP,  or  CRESP  depending  on  the  response  type 
specified  in  row  1.  For  example,  if  the  response  type  value  is 
2005,  the  pointer  would  point  to  the  location  in  the  RESP  array 
where  the  response  universe  information  begins.  If  the  response 
type  value  is  >1*000,  the  value  in  row  3  will  be  zero  since  each 
individual  response  list  in  the  mixed  response  will  have  its  own 
response  universe. 

Row  U 1 s  value  indicates  how  many  default  values  are  stored 
in  the  response  universe  array  for  a  response.  For  defined  length 
lists,  this  value  must  nqual  the  last  digit  in  the  response  type 
value  or  he  zero  (no  default  value(s)  for  the  response).  For  example, 
if  the  response  type  value  is  2003,  the  value  in  row  1*  must  be  3  or 
0.  If  the  response  universe  was  specified  to  be  >100,  the  value  in 
row  1*  must  not  be  0  ( storage  must  be  available  to  save  updated  default 
values ) . 

Row  5*s  value  indicates  how  many  enumerated  values  (valid 
values  for  a  response)  are  stored  in  the  response  universe  array  for 
a  response.  This  value  must  be  0  unless  the  response  universe  type 
value  was  1*  or  10l*.  If  a  response  is  from  a  set  of  enumerated  values, 
then  the  default  values,  if  there  are  any,  must  also  be  from  the 
enumerated  set- 


Table  II-l 


Response  Type  Values 

Value 

Response  Must  Be  a  List  of  n 

1000  ♦  n 

integers 

2000  +  n 

reals 

3000  ♦  n 

character  strings 

4000  +  n 

mixed  types 

NOTE:  If  n  *  0  the 
n  must  not  be 
is  4000  +  n. 

response  list  is  of  unspecified  length. 
i  zero  if  the  response  type  value  is 

% 

Table  II-2 

Response  Universe  Type  Values 

Value 

Response  Universe  Type 

1  or  101 

response  has  an  upper  and  a 
lower  bound 

2  or  102 

response  has  an  upper  bound  only 

|l  3  or  103 

!  i 

response  has  a  lower  bound  only 

4  or  104 

5  or  105 


response  must  be  equal  to  an 
enumerated  value 

no  limitations  on  the  value  of 
the  response 


2-U.  RESP(NR) ,  NRESP(NI) ,  CRESPjNC)  are  the  RESPONSE 
UNIVERSE  arrays  used  to  store  default  values,  enumerated  values, 
and  range  boundaries  for  the  responses.  RESP  is  used  to  store 
real  number  response  universe  values.  NRESP  is  used  to  store 
integer  number  response  universe  values,  and  CRESP  is  used  to 
store  character  string  response  universe  values. 

All  the  values  stored  in  a  response  universe  array  for  a 
particular  response  are  contained  in  a  contiguous  block  of  elements. 
Two  typical  blocks  of  elements  are  shewn  in  Figure  II-2.  The 
minimum  number  of  elements  in  a  block  is  two,  one  for  each  of  the 
range  boundaries  whether  they  exist  or  not. 

The  dimension  of  the  response  universe  arrays  (NR,  NI,  HC) 
are  passed  as  formal  subroutine  parameters  to  the  FFSP  subprograms. 


3-0  OUTPUT  DATA  STRUCTURE 


The  output  data  from  the  FFSP  routines  is  loaded  into  variables 
in  the  COM01S  common  block.  The  data  arrays  that  make  up  the  out¬ 
put  data  structure  are  illustrated  in  Figure  II-3.  The  next  few 
subsections  describe  these  variables. 

3-1.  INDEXS(NDEX,4)  is  an  INTEGER  array  used  to  store  pointers 
to  the  prompts  and  the  response  output  arrays  (ROUTS,  IOUTS,  and 
COUTS).  Each  row  represents  a  different  response  list  that  was 
entered.  The  mixed  response  lists  will  occupy  more  than  one  row  of 
the  INDEXS  array  (one  row  for  each  response  list  that  makes  up  the 
mixed  response  type).  The  response  type  values  greater  than  1+000 
will  not  appear  in  the  INDEXS  array.  Only  the  components  of  the 
mixed  response  types  are  contained  in  INDEXS.  The  definitions  of 
each  of  the  columns  of  this  array  are  explained  below. 


Column  1 
Column  2 


Column  3 


Column  1+ 


Response  type 

Location  in  the  response  output 
array  (of  the  type  indicated  by 
the  response  type  ii  column  1) 
of  the  first  response  in  the 
response  list. 

Location  in  the  response  output 
array  of  the  last  response  in 
the  response  list. 

The  prompt  number.  (The  position 
in  the  PROMPT  array.) 
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Block  for  a  response  with  2  default  values  and  4  enumerated  values. 


Block  for 
response  1 


> 


Default  values 


Fnumerated  values 


-J 


Block  for  response  with  1  default  value  and  0  enumerated  values. 


Block  for 
response  i 


Figure  II-2.  Block  of  Elements  in  a  Response  Universe  Array. 


3-2.  RCUTS(NRO)  .IOLTS(NIO) tCOUTS(NCO)  are  the  RESPONSE 
OUTPUT  arrays.  These  arrays  contain  all  the  responses  entered  by 
the  user  for  a  command.  The  dimensions  of  these  arrays  (NRO,  NIO, 
NCO)  are  set  with  a  PARAMETER  statement  in  eveiy  routine  with  the 
COM01S  common  block. 

3-3-  I  FAROS , I  FA I OS ,  and  IFACOS  are  POINTERS  to  the  next 
available  locations  for  scoring  responses  in  ROUTS,  IOUTS,  and  COUTS 
respectively. 


III.  FLOW  OF  CONTROL 


1-0  DESCRIPTION  OF  FFSP  FLOW  OF  CONTROL 

The  flov  of  control  between  the  MOPADS  user  interface  and 
the  FFSP  programs  is  illustrated  in  Figure  III-l.  There  are  six 
logical  entry  points  to  the  FFSP  programs  (RCMDS,  SPROCL,  ACCESS, 
HELPS,  6ETSUS,  and  IN ITS ) .  If  any  of  the  FFSP  subroutines  detect 
an  error  in  the  data  structure  (not  user  input  errors),  execution 
will  be  terminated. 


NOTE 


It  is  important  to  extensively  debug 
the  data  structure  in  I  the  routines 
that  call  the  FFSP  programs. 

*  f  l ' 

The  FFSP  subroutines  are  supported  by  the  FFIN2  programs  (Polito), 
and  the  MOPADS  utility  programs  (Goodin,  Polito).  j 

The  primary  entry  point  to  the  actual  syntax  processor  is  j 
subroutine  SPROCS.  There  are  tnree  logical  paths  through  the 
syntax  processor  (see  Figure  III-l)  depending  on  the  form  in  which 
the  command  was  entered.  If  the  system  encounters  "CMC"  for  a 
prompt  or  response,  control  is  returned  to  the  command  subroutine 
with  an  indication  that  the  command  was  cancelled. 


* 


IV.  FILES 


1-0  FFSP  FILES 

There  ere  two  files  used  by  the  FFSP  routines,  1)  the  inter¬ 
active  terminal  input  file  and,  2)  the  interactive  terminal  output 
file.  The  input  file  is  used  to  enter  commands,  prompts,  responses, 
and  corrections  to  the  syntax  processor.  'Hie  output  file  is  used 
to  output  prompts,  error  messages  and  general  information  to  the 
user. 


The  default  unit  nur hers  for  the  input  and  output  files  are 
5  and  6,  respectively.  Their  value-;  are  assigned  to  the  variables 
NREADS  (input)  and  NPRNTS  (output)  oi  the  COM01S  common  blork.  This 
assignment  is  performed  in  the  BLOCKS  block  data  subprogram  with  a 
DATA  statement.  These  value*  may  be  changed  with  r.  call  to  the 
INITS  subroutine.  The  following  example  demonstrates  how  the  values 
for  the  input  and  output  unit  numbers  may  be  changed  to  9  and  15, 
respectively. 


EXAMPLE: 


LIN  «  9 

LOUT  -  15 

CALL  INITS  (LIN,  LOIF,  *  •) 


V.  SUBPROGRAMS 


1-0  INTRODUCTION 

The  subprograms  that  make  up  the  FFSP  module  may  be  divided 
into  two  groups: 

1.  Those  that  process  syntax,  and 

2.  Service  or  utility  routines. 


2-0 !  SYNTAX  PROCESSOR  ROUTINES 

I  These  routines  contain  the  logic  to  decode  U3er  commarda 
into  the  response  output  arrays.  These  routines  are  discussed  in 
the  following  subsections. 

2-1.  Subroutine  SPROCS  is  the  primary  entry  point  to  the 
syntax  processor.  It  analyzes  the  command  entered  by  the  user  and 
decides  which  form  ( command-name-only ,  regular  mode,  concise  mode) 
the  command  Is  in.  One  of  the  following  routines  will  be  called 
by  SPROCS  depending  on  the  command  form: 


1. 

SCOPRS 

canaan d- name-only 

2. 

SCRPRS 

regular  mode 

3. 

SCCPRS 

concise  mode 

After  control  is  returned  to  SPROCS  and  no  errors  are  detected, 
subroutine  UPCJTS  is  called  to  update  any  updated  default  responses. 
Figure  V— 1  shows  the  calling  sequence  and  defines 
the  parameters  of  SPROCS. 

2-2.  Subroutine  SCOPRS  is  used  to  decode  the  commands  entered 
in  the  command-name-only  fora.  It  is  also  called  if  an  error  is 
detected  in  a  command  entered  in  regular  mode  or  concise  mode.  If 
an  error  occurs  in  a  response,  the  system  will  re-prompt  for  a  valid 
response.  Figure  V-2  shows  the  calling  sequence  and  defines  the 
parameters  of  SCOPRS. 

i  2-3.  Subroutine  5CRPRS  is  used  to  decode  the  commands  entered 
in  regular  mode.  If  an  error  if  detected  in  one  of  the  prcmpt- 
response  groups,  all  the  prompt-response  groups  after  and 
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Figure  V-2.  8UBR0UTIH8  SCOPRS 


including  the  one  with  the  error,  will  not  "be  accepted.  Control 
is  passed  to  subroutine  jCQPRS,  and  the  system  will  prompt  the 
user  for  all  un-en;ered  responses.  Figure  V-3  shows  the  calling 
sequence  and  defines  the  parameters  of  SCRPRS. 

2-L.  Subroutine  SCCPRS  is  used  to  decode  the  commands 
entered  in  concise  mode.  If  an  error  is  detected  in  one  of  the 
response  lists,  all  the  response  lists  after  and  including  the  one 
with  the  error  will  not  be  accepted.  Control  is  passed  to  subrou¬ 
tine  SCOPRS,  and  the  system  will  prompt  the  user  for  all  unentered 
responses.  Figure  V-L  shows  the  calling  sequence  and  defines  the 
parameters  of  SCCPRS. 

2-5.  Subroutines  GET CHS,  GET  INS,  GETRLS  and  MLTGTS  are  used 
to  retrieve  the  responses  entered  by  the  user.  GET CHS  is  used  to 
retrieve  character  response  lists.  GETINS  is  used  to  retrieve 
integer  response  lists.  GETRLS  is  used  to  retrieve  real  response 
lists.  MLTGTS  is  used  to  call  the  necessary  routines  (GETCHS, 

GET INS,  and/or  GETRLS)  to  retrieve  mixed  responses.  These  routines 
use  subroutines  CHCVLS,  CHIVLS,  CHRVLS,  and  CHFLDS  to  check  fields 
for  validity  and  special  case  entries  such  as  "DEF"  and  "CANC." 

Figure  V-5  shows  the  calling  sequences  and  defines  the  parameters  of 
GETCHS,  GET I NS,  GETRLS,  and  MLTGTS. 

2-6.  Subroutines  CHCVLS,  CHIVLS,  and  CHRVLS  are  used  to  check 
the  validity  of  responses  retrieved  by  GETCHS,  GETINS,  and  GETRLS 
respectively.  These  routines  may  check  a  response  to  see  if  it 
exceeds  the  upper  and/or  lower  bounds  on  the  response.  The  responses 
may  also  be  checked  to  see  if  they  equal  an  enumerated  value. 

Figure  V-6  shows  the  calling  sequences  and  defines  the  parameters 
of  CHCVLS.  CHIVLS,  and  CHRVLS. 

2-7.  Subroutine  CHFLDS  is  used  to  check  responses  for  the 
correct  type  (character,  integer,  or  real)  and  to  detect  the  special 
case  responses  "DEr"  and  "CANC."  Th.'.s  routine  has  five  alternate 
returns  for  special  conditions  or  errors  that  are  detected.  Figure 
V-7  shows  the  calling  sequence  and  defines  the  parameters  of  CHFLDS. 

2-8.  Subroutine  CHOSHS  is  used  to  detect  a  dash  at  the  end  of 
a  command- response  list.  If  the  character  is  detected,  a  flag  is  set 
on  (*>1)  and  the  dash  is  replaced  with  a  blank.  Figure  V-8  shows  the 
calling  sequence  and  defines  the  parameters  of  CHDSHS. 

2-9.  Subroutines  LDDFVS  and  ML7LDS  are  used  to  load  the  default 
value(s)  into  the  response  output  arrays.  Subroutine  LDDFVS  is 
called  when  the  user  enters  "DEF"  for  a  response  or  he/she  has  elected 
to  take  some  of  the  default  responses.  MLTLDS  is  called  from  LDDFVS 
when  the  system  is  loading  the  default  values  for  a  mixed  response  type. 
Figure  V-9  shows  the  calling  sequences  and  defines  the  parameters  of 
LDDFVS  and  MLTLDS. 
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Figure  V-6.  SUBROUTINES  CHCVLS',  CHIVLS,  and  CHRVLS. 
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Figure  V-6.  (continued) 
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Figure  V-7.  SUBROUTINE  CHFLDS 


SUBROUTINE  CHDSHS  ( CHAR # I SFT ) 
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Figure  V-9.  SUBFOITTINES  LDDFVS  and  MLTLDS 
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Figure  V-9.  (continued) 


2-10.  Subroutines  DCFS  and  LDDEFS  are  used  to  load  t.  buffer 
with  default  values  to  be  printed  after  a  prompt  when  the  user 
enters  a  command  in  the  coranand-name- only  form.  If  no  default 
value(s)  is  detected  the  buffer  is  loaded  with  the  text  "HO  DEFAULT." 
These  routines  are  set  up  to  allow  the  buffer  to  be  printed  in 
several  lines  if  necessary.  The  maximum  number  of  lines  that  will 
be  printed  is  determined  by  the  value  of  the  parameter  DBLEN.  Thin 
parameter  is  set  in  a  PARAMETER  (DFLcN  *  ...)  statement  in  sub¬ 
routine  SCOPRS.  Figure  V-10  shows  the  calling  sequences  and  defines 
the  parameters  of  OEFS  and  LODEFS. 

2-11.  Subroutine  UPDTS  is  used  to  update  default  values  that 
require  updating  every  time  a  new  response  is  entered  for  a  par¬ 
ticular  prompt.  This  routine  is  called  by  SPRGCS  and  updates  the 
default  values  only  if  no  errors  were  detected  by  the  syntax  pro¬ 
cessor  routines.  Figure  V-U  shows  the  calling  sequence  and  defines 
the  parameters  of  UPDTS. 

2-12.  Subroutine  INITS  is  used  to  initialize  options  for  the 
FFSP  module.  These  variables  include  the  following: 

1.  input  unit  number  (NREADS) 

2.  output  unit  number  (NPRNTS) 

3.  <V»fault  mode  (MODES) 

Figure  V-12  shows  the  calling  sequence  and  defines  the  parameters 
of  INITS.  The  user  should  call  INITS  prior  to  using  any  other 
FFSP  program.  If  he  does  not,  NREADS  will  be  5,  NPRNTS  will  be  6 
and  the  default  mode  will  be  regular.  INITS  may  be  called  at  any 
time  to  change  the  values  of  these  options. 


3-0  SERVICE  AND  UTILITY  ROUTINES 

3-1.  Subroutine  INITS  can  also  be  called  as  a  utility 
routine  to  change  FFSP  options.  See  Section  V,  2-12. 

3-2.  BLOCKS,  Block  Data  Subprogram,  is  used  to  initialize 
COMJilS  common  block  variables.  These  variables  are  initialized 
before  execution  begins.  The  variables  are  as  follows: 

1.  NREADS 

2.  NPRNTS 

3.  MODES 

1*.  INITS 

See  Section  VIII  for  descriptions  of  these  variables. 
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Figure  V-10.  SUBrtOUTINIS  DEFS  and  LDDEFS 
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3-3-  Subroutine  GETSVS  is  used  to  retrieve  the  values  of 
FFSP  options.  These  options  are: 


1. 

N READS  - 

input  file  number 

2. 

NPRNTS  - 

output  file  number 

3. 

MODES  - 

mode 

Figure  V-13  shows  the  calling  sequence  and  defines  the  parameters 
of  GETSVS. 

3-U.  Subroutine  RCMDS  is  used  to  read  the  first  field  of  the 
command  input  (the  command  itself).  This  subroutine  does  no  validity- 
check  on  the  command,  but  returns  the  command  name  entered. 

Figure  V-lU  shows  the  calling  sequence  and  defines  the  parameters  of 

RCMDS. 


3-5*  Subroutine  HELPS  is  used  to  print  information  about  the 
user  command.  The  user  is  asked  to  enter  a  promt  name  for  which 
information  is  desired.  The  foilwing  information  is  printed  for 
any  prompt: 


1.  Prompt  name  (unabbreviated) 

2.  Response  type  (character,  integer,  real  or  mixed) 

3.  Default  values,  if  any 


1 


U.  Enumerated  values,  if  any 

5.  Upper  and/or  lower  bounds  on  the  response 

Figure  V-15  shows  the  calling  sequence  and  defines  the  parameters 

of  HELPS. 

3-6.  Subroutine  ACCESS  is  used  to  access  the  response  in  the 
response  output  arrays  (ROUTS,  IOUTS,  COUTS) .  This  routine  should  only 
be  called  after  calling  SPROCS  and  generating  no  errors  while  in 
SPROCS.  Figure  V-l6  shows  the  calling  sequence  and  defines  the  para¬ 
meters  of  ACCESS. 
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Figure  V-15.  SUBHOUTINE  HELPS 
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V-16.  6UBR01/TIHE  ACCESS 


VI.  USER  INSTRUCTIONS 


1-0  COMMAND  DATA  SPECIFICATION  FORM 


When  designing  the  data  structure  for  a  user  c remand  that 
will  use  ihe  FFSP,  the  user  should  fill  out  the  Command  Data  Speci¬ 
fication  form.  An  example  of  this  form  is  shown  in  Figure  VI-1. 

The  next  two  subsections  will  discuss  how  this  fora  is  completed 
and  used  to  design  the  data  structure. 


1-1.  Instructions  for  Preparing  The  Command  Data 
Specification  Form. 

The  letters  that  are  circled  in  the  following  instruc¬ 
tions  correlate  with  their  placement  in  Figure  VI-2. 

1)  Write  the  name  of  the  command  in  space  (a). 

2)  Put  the  name  of  the  module  in  space  (b). 

3)  Write  the  original  or  revision  date  in  space  (c) . 
U)  Briefly  explain  the  purpose  of  the  command  in 


space 


©. 


5)  Write  a  prompt  name  in  space  ©. 


6)  Determine  the  response  type  from  the  following 
(n  is  the  length  of  the  list  of  values;  if  n*5l  the  list  is  of 
undefined  length). 


Code 

1000+n 
2000+n 
3000+n 
i<000+n* 

NOTE 

For  the  mixed  response  type,  n  is  the  number  of  other 
response  type  specifications  making  up  the  response 
(e.g.,  if  a  mixed  response  is  rrde  up  of  1001,  2003, 

1002,  and  3001  response  types,  the  mixed  response  type  would 
be  equal  to  hOOU ) .  N  can  not  be  equal  to  zero  for  a 
mixed  response  type  and  none  of  the  response  types 
included  in  a  mixed  response  type  may  have 


Response  Type 

list  of  a  integer  values 
list  of  n  real  values 
list  of  n  character  values 
mixed  response 
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VI.  USER  INSTRUCTIONS 


1-0  COMMAND  DATA  SPECIFICATION  FORM 

When  designing  the  data  structure  for  a  user  command  that  will 
use  the  FFSP,  the  user  should  fill  oat  the  Canaan d  Data  Specifica¬ 
tion  fora.  An  example  of  this  fora  is  shown  in  Figure  VI -1.  A  full 
sized  “blank  Command  Data  Specification  fora  is  provided  at  the  end 
of  the  report.  The  next  two  subsections  will  discuss  how  this  form 
is  completed  and  used  to  design  the  data  structure. 


1-1.  Instructions  for  Preparing  The  Command  Data 
Specification  Form. 

The  letters  that  are  circled  in  the  following  instruc¬ 
tions  correlate  with  their  placement  in  Figure  VI-2. 

1)  Write  the  name  of  the  command  in  space 

2)  Put  the  name  of  the  module  in  space  (b) . 

3)  Write  the  original  or  revision  date  in  apace  (c ). 


space 


U)  Briefly  explain  the  purpose  of  the  command  in 


5)  Write  a  prompt  name  in  space  (E). 


6)  Determine  the  response  type  from  the  following 
(n  is  the  length  of  the  list  of  values;  if  n*#  the  list  is  of 
undefined  length). 


1000+n  list  of  n  integer  values 

2000+n  list  of  n  real  values 

3000+n  list  of  n  character  values 

UOOO+n*  mixed  response 


NOTE 

For  the  mixed  response  type,  n  is  the  number  of  other 
response  type  specifications  making  up  the  response 
(e.g.,  if  a  mixed  response  is  made  up  of  1001,  2003, 

1002,  and  3001  response  types,  the  mixed  response  type  would 
be  equal  to  booU).  N  can  not  be  equal  to  zero  for  a 
mixed  response  type  and  none  cf  the  response  types 
included  in  a  mixed  response  type  may  have 


COMMAND  DATA  SPECIFICATION  page 


Write  the  code  value  for  the  response  type  in  space  (^F) .  If  the 
mixed  lesponse  type  is  selected,  steps  6  through  10  will  he 
repeated  for  each  response  type  making  up  the  response. 

7)  Determine  the  response  universe  type  from  the 
following  (where  numbers  greater  than  100  represent  responses  with 
updated  default  values). 


Code  Response  Universe  Type 


1  or  101 

response  must  be  between  upper 

and  lower  bound 

2  or  102 

response  has  an  upper  bound  only 

3  or  103 

response  has  a  lover  bound  only 

4  or  104 

response  must  be  from  a  set  of 

enumerated  value(s) 

5  or  105 

any  response  of  the  type 

specified  is  acceptable 

For  e.*'xunple,  if  a  response  must  he  between  1  and  100,  the  response 
universe  type  would  be  1  or  101  depending  on  the  status  desired  for 
the  default  values.  If  a  response  must  be  either  "1","3",  or  "5",  the 
response  universe  type  would  be  4  or  104. 

Write  the  code  value  for  the  response  universe 

type  in  space 

8)  Write  any  default  value(s)  in  space  (h).  The  values 
m:ist  conform  to  the  response  universe  specified  in  step  7  and  the 
response  type  specified  in  step  6  .  If  there  are  no  defaults,  leave 
this  space  blank. 

9)  If  4  or  104  was  selected  for  the  response  universe 
type  in  step  7  ,  write  the  enumerated  values  in  space  (T).  If  any 
other  code  was  entered,  leave  this  space  blank. 

10)  If  the  response  universe  code  selected  in  step  6 
was  1,  101,  2,  102,  3  or  103,  the  values  for  the  lower  and/or  upper 
bounds  must  be  written  in  spaces  (j)  and  @,  respectively.  Upper 
and/or  lower  bounds  may  be  specified  with  response  types  of  "3000+n,,r 
but  the  user  should  be  aware  that  the  character  collating  sequence 

is  system  dependent,  and  the  resulting  specification  may  not  be 
portable. 

11)  Repeat  steps  5  through  10  for  all  the  prompts. 

An  example  of  a  completed  "Command  Data  Specification  Form"  is 
shown  ir.  Figure  VI-3. 


vV 
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Creating  The  Actual  Data  Structure  From  The  Command 
Da-!  a  Specification  Form. 


The  user  needs  to  construct  the  arrays  PROMPT,  KPMTS, 
LTAX,  NRESP,  CRESP,  and  RESP  from  the  information  entered  in  the 
Command  Data  Specification  form.  The  data  structure  can  he  created 
with  the  following  steps.  (Figure  VI-U  is  an  example  data  structure 
created  using  the  form  in  Figure  VI- 3. ) 


l)  Load  the  prompt  names  into  the  PROMPT  array  in 
the  same  order  as  they  appear  on  the  form.  Note  the  number  of 
prompt  names  and  equate  this  to  the  variable  NPMTS  (the  variable 
name  used  by  the  FFSP  routines  for  the  number  of  prompt  names  for 
a  given  command. 


2)  Put  the  response  type  code  values  into  the  first 
row  of  the  LTAX  array. 

3)  Flit  the  response  universe  type  code  values  into 

the  second  row  of  the  LTAX  array.  * 

L)  Note  the  number  of  defaults  for  each  response  list 
and  put  this  value  into  the  fourth  row  of  the  LTAX  array. 


5)  Note  the  number  of  enumerated  values  for  each 
response  list  and  put  this  value  into  the  fifth  row  of  the  LTAX 
array. 


NOTE 


The  third  row  of  the  LTAX  array 
will  be  completed  at  the  time  the 
response  universe  arrays  are  created 
(arrays  RESP,  NRESP,  and  CRESP). 

|  6)  The  KPMTS  array  contains  pointers  to  the  LTAX 

ariray  where  the  information  for  the  corresponding  prompt  (infor- 
maiion  in  row  3  or  KPMTS  is  for  the  third  prompt)  begins.  These 
pointers  ore  loaded  into  the  first  column  of  the  array.  The 
remainder  is  left  uninitialized. 


7)  Now  fill  the  response  universe  arrays  (NRESP,  CRESP, 
RESP).  Scan  the  columns  of  LTAX  starting  at  column  1  and  skipping 
any  column  whose  first  row  value  is  greater  than  LOOO. 
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DIMENSION  PR0MPT(4),  KPMTS(4,2),  LTAX(5,8),  kESP(6) 

DIMENSION  NRESP(IO),  CRESP(14) 

CHARACTER  CRESP*  1  ,  PR0MPT*8 


DATA  PROMPT  /  *  JOBTITLE  * , 
'PAYHOUR', 
'NUMSECRT' , 
'BLD6C0DE'  / 


DATA  ( (LTAX( I »J) ,J= 1,8) , 1=1,5) 
/  2-OGO,  2001,  1001,  4004, 

5,  1,  104,  0, 

1,  1,  1,  0, 

0,  1,  1,  0, 

0,  0,  3,  0, 


3001,  1002,  3001,  2001, 

4,  1,  4,  102, 

3,  7,  10,  4, 

1,  2,  1,  1, 

4,  0,  2,  0/ 


DATA  (KPMTS( 1,1),  1=1,4)  /1,2,3,4/ 


DATA  CRESP  /' 


i«i  i  i  i  i  i*i  ini  * r i 
,n,  ,  ,  n  ,  v  ,  w  , 


•D'.'E',' 


i  i  i  iri  • pi 
•  »  t-  ,  r 


DATA  NRESP  /l, 0,0, 1,3, 5, 1000, 1001, 1000, 5000/ 


DATA  RESP  /10. 0,0. 0,100. 0,6. 0,0.0, 10.0/ 

NTAX  =  8 
NPMTS  =  4 
NR  =6 
NC  =  14 
NI  =  10 


Figure  VI-1*.  Example  Data  Structure. 


ft)  For  each  column  of  LTAX  select  the  correct  response 
universe  array  as  follows: 


Response  Type  Code 
(row  1  of  LTAX) 

1001+n 

2000+n 

3000+n 


Response  Universe 
_ Array _ 

NRESP 

RESP 

CRESP 


9)  Note  the  element  number  of  the  next  available  element 
in  the  current  response  universe  array.  Put  this  number  in  row  3 
of  the  current  LTAX  column. 


10;  Load  values  into  the  next  several  elements  of  the 
current  response  universe  array  according  to  the  rules  in 
Figure  VI-5. 


LTAX. 


11)  Repeat  steps  8  through  10  for  each  column  of 


12)  Note  the  defined  lengths  of  NRESP,  CRESP,  and  RESP 
for  use  in  DIMENSION  statements  as  formal  parameters  when  calling  FFSP 
programs .( Not e  NTAX,  NPMTS,  NR,  NC,  NI  in  Figure  VI-L.) 

It  is  worthwhile  to  stop  now  and  attempt  to  duplicate  the  contents 
of  NRESP,  CREST', and  RESP  in  Figure  VI-L  from  the  specifications  in 
Figure  VI-3.  This  process  is  very  easy  once  a  little  practice  is 
obtained. 


2-0  WRITING  AND  USING  THE  COMMAND  SUBROUTINES 
2-1 .  Use  Of  Subroutine  ACCESS. 

Subroutine  ACCESS  has  the  following  calling  sequence: 

SUBROUTINE  ACCESS(IPRMTN,NORDEP,NNN,JRTCD,RSP, 
NNR,IR$P,NNI ,CRSP ,NNC,IDFLG) 

The  definitions  of  the  parameters  can  be  found  in  Section  V,  2-6. 

This  subroutine  retrieves  the  responses  for  a  specified  prompt 
by  searching  the  INDEXS  array  (in  COM01S  common  block)  for  the  desired 
prompt  number.  Once  the  number  has  been  found,  the  exact  location  of 
the  responses  can  he  determined.  The  designer  of  the  command  sub¬ 
routines  must  set  up  three  additional  arrays  for  storing  responses 
retrieved  by  the  call  to  ACCESS.  These  arrays  are  CRSP  for  character 
string  responses,  IRSP  for  integer  responses,  end  RSP  for  real 
responses.  NNN  is  s  variable  Tised  to  pass  the  dimension  of  the  three 
response  arrays  to  ACCESS.  NNN  should  be  set  equal  to  the  maximum 
number  of  responses  of  one  type  that  may  be  entered  for  a  response. 


V 


/ 


a.  Response  Universe  Type 
*  1  or  101 


b.  Resnonse  Universe  Type 
-  2  or  102 


Default  Values 
(if  any) 

Lower  bound 
Upper  bound 


c.  Response  Universe  Type 
*  3  or  103 


Default  Values 
(if  any) 

Lower  bound 

Any  value 


e.  Response  Universe  Code 
=  5  or  105 


Default  Values 
(If  any) 

Any  value 
Upper  bound 


d.  Response  Universe  Type 
*  4  or  104 


Default  Values 
(if  any) 

Any  value 

Any  value 


Default  Values 
(if  any) 

Any  value 

Any  val ue 


Enumerated 

Values 


Figure  VI-5.  Loading  Response  Universe  Arrays  Based  On  The 
Response  Universe  Type. 
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To  use  the  ACCESS  subroutine  the  user  must  know  the  prompt 
number  (the  order  in  PROMPT  array)  for  the  response  he  desires, 
the  response  tyoe  (integer,  real,  character  string),  and  the  order 
of  the  response  list  (1,  2,  3,  etc.)  in  a  mixed  response  (if  not 
from  a  mixed  response  the  order  is  zero).  The  subroutine  will 
return  the  responses  in  one  of  the  response  arrays  (IRSP,  RSP,  or 
CRSP),  depending  on  the  response  type  specified.  The  response 
array  with  values  in  it  will  have  a  no.i-zero  indicator  value 
returned  from  ACCESS,  the  other  two  indicators  vill  be  equal  to 
zero.  These  indicators  are:  NNI  for  the  number  of  integer  responses, 
NNR  for  the  number  of  real  responses,  and  NNC  for  the  number  of 
character  string  responses 

Figure  VI-6  illustrates  the  use  of  the  ACCESS  subroutine  for 
various  cases. 

2-2 .  Writing  The  Command  Subroutines. 

Figure  VI-7  illustrates  how  the  data  structure  and  the 
calls  to  the  FFSP  routines  are  placed  in  a  command  subroutine. 

SPROCS  decodes  the  command.  ACCESS  is  used  to  retrieve  the  responses 
from  the  decoded  command.  HELPS  is  used  to  print  information  con¬ 
cerning  the  command,  if  the  command  has  no  prompts,  do  not  issue  calls 
to  SPROCS,  ACCESS,  or  HELPS  (These  routines  are  to  be  used  only  with 
commands  that  have  prompts). 


3-0  ADDITIONAL  INSTRUCTIONS 

\  3-1.  How  To  Change  Modes. 

+ 

\  The  default  mode  cay  be  changed  with  a  call  to  subroutine 

IN  ITS .  The  following  examples  show  how  to  change  the  default  mode  to 
t  concise  mode. 

■  CHARACTER  M0DE*1 

"*  • 

::  MODE  »  *C' 

/  CALL  INITS  (0,0, MODE) 

t  or 

“  CALL  INITS  (0,0, 'C' 

■1  To  change  the  default  mode  to  regular  mode  the  user  would  use  'R' 

in  place  of  * C* .  For  example, 

i  CALL  INITS  (0,0, ’ R* ) 

r. 

;  A 

i  f 

i 

I 
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ADDITIONAL  NOTES  -  NNN  must  have  a  value  greater  than  or  equal  to  1  since  It  Is  the  dimension  for 
RSP.CRSP,  and  IRSP.  If  the  respdnse(s)  returned  by  ACCESS  were  the  default 
response(s) ,  IOFLG  will  be  returned  equal  to  1.  If  the  user  entered  a  response 
1 1st  and  did  not  take  the  default,  IDFLG  will  returned  equal  to  1. 


SUBROUTINE 

HORKI  (IOPT) 

”’HENSION 

RSP(1).CRSP(10).NRSP(2) 

CHARACTER 

CRSP*20 

data  statements  FROM  FIGURE  VI -4 


c 

C**OECODE  CMWIO 

c 

IF  (IOPT.EQ.l)  GO  TO  900 

CALL  SPROCS  (PROMPT.NPHTS.LTAX.NTAX.RESP.NR.NRESP.NI, 
CRESP.NC.KPMTS.ICNCL) 

IF  (iaa.EQ.1)  GO  TO  999 

c 

C**GET  RESPONSE  TO  PROMPT  ONE 
C 

NNN  •  10 

CALL  ACCESS  ( 1.0.NNN.3,RSP,NNR.IRSP,RNI  .CRSP.MtC.IOaG) 
S  RESPONSE  PROCESSING  LOGIC 
C 

C'^GET  RESPONSE  TO  PROMPT  THREE 

C 

NNN  •  2 

CALL  ACCESS  (3.0,NNN.1.RSP,NNR.IRSP,NNI,CRSP.NNC.IDFIG) 

• 

J  RESPONSE  PROCESSING  LOGIC 
}  SIMILAR  PROCESSING  OF  OTHER  PROMPTS 
GO  TO  999 

C  * 

C**H&P  COWAN 0  HAS  ENTERED 

900  CAU  HELPS  { 'WORKINFO' .PROMPT ,NPMTS,KPMTS,LTAX,NYaX, 
RESP ,NR .NRESP ,NI .CRESP ,NC ) 

GO  TO  999 
C 

999  RETURN 
END 


Figure  VI-7.  Example  of  Command  Subroutine  for  Example 
Command  from  Figure  VI-3. 
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3-2 .  Hov  To  Change  The  Input  And  Output  Unit  Numbers . 

The  default  Input  and  output  unit  numbers  established  with 
the  block  data  subprogram  BLOCKS  may  be  changed  by  a  call  to  sub¬ 
routine  IN  ITS.  The  following  example  shows  how  to  change  the  input 
and  output  unit  numbers  to  9  and  10  respectively. 

CALL  INITS  (9,10,'  ') 

3-3*  How  To  Retrieve  The  Values  For  The  Mode  And  Input 

And  Output  Unit  Numbers. 

These  valuer  may  be  retrieved  with  subroutine  GETSVS. 

For  example  to  retrieve  the  value  of  the  mode  in  JMODE  and  the  values 
of  the  input  and  output  unit  numbers  in  IN  and  IOUT  respectively,  use 
the  following  call  to  GLTSVS, 

CHARACTER  JMODE  *1 
CALL  GETSVS  ( IN .IOUT, JMODE) 
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VII.  ERROR  PROCESSING 


1-0  FFSP  ERRORS 

There  are  three  type3  of  errors  that  may  be  detected  by  the 
EFSP  subroutines.  The  error  message  that  is  printed  is  preceded  by 
an  error  type  identifier.  These  identifiers  sore  as  follows: 

1.  I/O  ERROR  — 

2.  DATA  STRUCTURE  ERROR-- 

3.  ACCESS  ERROR  — 

1-1.  I/O  errors  are  generated  in  the  syntax  processor  routines 
that  decode  the  user  commands.  These  errors  are  generated  by  invalid 
user  input  (response)  values.  The  user  will  be  promted  to  re-enter 
the  responses  if  one  of  these  errors  occur.  These  are  the  least 
severe  errors.  FFSP  automatically  corrects  for  these  problems,  and 
execution  is  never  terminated  because  of  an  I/O  error. 

1-2.  Data  structure  errors  are  generated  when  errors  in  the 
user  defined  data  structure  are  detected.  These  errors  are  created 
by  situations  such  as  invalid  response  type  code,  invalid  response 
universe  type  codes,  and  by  exceeding  the  dimensions  of  some  array. 
Data  structure  errors  should  occur  only  during  the  debugging  phase 
of  developing  a  program  that  uses  FFSP.  These  are  severe  errors  and 
FFSP  will  terminate  execution  if  it  detects  an  invalid  input  data 
structure. 

1-3.  ACCESS  errors  are  generated  in  the  ACCESS  subroutine  by 
illegal  parameter  values  or  by  exceeding  the  dimension  of  an  array. 
These  errors  will  also  cause  execution  to  terminate.  Errors  in  the 
use  of  the  ACCESS  subroutine  should  occur  only  during  the  debugging 
phase  of  program  development. 
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VIII.  COmON  VARIABLE  DEFINITIONS 


1-0  FFSP  COMMON  BLOCKS 

The  FFSP  routines  use  two  common  blocks  (COM01S  and  COM02S). 
COM01S  canmon  block  contains  numerical  data  and  tbs  COM02S  -ommon 
block  contains  character  data.  The  COM01S  variables  and  their 
definitions  are  listed  in  Table  VIII-1.  The  COM02S  variables  and 
their  definitions  are  listed  in  Table  VIII-2. 

User  programs  never  access  any  of  these  variables  directly. 
Therefore,  it  is  not  necessary  for  user  programs  to  contain  the  FFSP 
common  statements. 
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Table  VTII-1 


COM01S  Common  Variables  and  Definitions 


Variable 

Definition 

ICNCLS 

Cancel  Command  Flag 

*  0  Coiranand  not  cancelled 

•  1  Command  cancelled 

IFACOS 

Pointer  to  the  next  available  location 
in  the  character  response  output  array, 
COUTS 

IFADXS 

j 

t 

Pointer  to  the  next  available  location  in 
the  INDEXS  array  for  storing  indeces  to 
the  response  output  arrays. 

IFAIOS 

Pointer  to  the  next  available  location 
in  the  integer  response  output  array 

I  OUTS 

I FAROS 

Pointer  to  the  next  available  location 
in  the  real  response  output  array  ROUTS 

UNITS 

Initialization  Flag 

*  0  Subroutine  INITS  was  called 

*  1  Subroutine  INITS  has  not  been  called 

INDEXS(NDEX,4)* 

Array  of  indeces  to  response  output  arrays 

( _ .1) 

Response  Type 

1000  -  1999  »  Integer 

2000  -  2999  -  Real 

3000  -  3999  »  Character 

( _ .2) 

Pointer  to  the  first  location  in  the 
response  output  array  (type  indicated  by 
column  1  value)  where  the  responses  art 
stored 

( _ »3) 

Pointer  to  the  last  location  in  the 
response  output  array  (type  indicated  by 
column  1  value)  where  the  responses 
are  stored 

(__.4) 

! 

Prompt  number  (negative  if  the  response 
entered  was  the  default). 

ioirrs(Nco)* 

Integer  response  output  array  for  storing 
integer  responses 
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Table  VIII-l  (Continued) 


Variable 

Definition 

NPRNTS 

Output  file  unit  number 

N RE AOS 

Input  file  unit  number 

ROUTS  (NRO)* 

Real  response  output  array  for  storing 
real  responses 

Table  VIII-2 

COM02S  Common  Variables  and  Definitions 


Variable 

Character  Length 

Definition 

COUTS(NCQ)* 

RSPLEN  * 

Character  response  output 
array  for  storing  character 

responses 

MODES 

1 

Current  command  mode. 

*  ’ R'  for  regular  mode 

*  'C'  for  concise  mode 

*N0TE-The  values  for  NCO,  NIO,  NRO,  NDEX,  and  RSPLEN  are  set  with  a 
PARAMETER  statement.  To  change  their  values  simply  alter  the 
required  portion  of  the  PARAMETER  statement  and  recompile  the 
source  code.  Current  values  for  their  PARAMETERS  are  NC0=50, 
NIV=100,  NR0=100,  NDEX=50,  and  RSPLEN=30. 
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Standard  KOPADS  Terminology 


AIR  DEFENSE  SYSTEM  A  component  of  Air  Defease  vhich  induces 

equipment  end  operators  sad  for  violet 
technical  sad  tactical  training  ererecuired. 
Bcamples  are  TEAKS  end  the  AN/TS<-73. 


Models  of  operator  actions  and  equiTaeut 
characteristics  for  Air  Defense  Systems  in 
the  HOPADS  software.  These  models  are  pre¬ 
pared  with  the  SATXT  simulation  language. 
Air  Defease  System  Modules  ieelurt#  the 
SAZ3T  model  and  all  data  needed  to  am¬ 
pler  ely  define  rash  element  times,  task 
sequencing  .requirements,  and  human  factors 
influences. 


A  spatial  and  temporal  record  of  aerial 
activities  and  characteristics  of  an  air 
defense  "beetle.  The  Air  Scenario  includes 
aircraft  tracks,  safe  corridors,  235,  and 
other  aircraft  and  airspace  data.  See 
also  Tactical  Scenario. 


A  term  used  in  the  SATST  simulation  lang¬ 
uage  to  mean  the  process  "by  vhich  TASK  nodes 
are  sequenced.  At  the  completion  of  the 
simulated  activity  at  a  TASK  node,  the 
branching  from  that  node  determines  vhich 
TASK  uodes  will  he  simulated  next. 


DATA  BASE  CONTROL  That  pert  of  the  KOPADS  software  which 

SYSTEM  performs  all  direct  eammnicction  with  the 

MDPADS  Data  Base.  All  inf  enaction  transfer 
to  and  froa  the  data  base  is  performed  by 
irrmhing  the  subprograms  vhich  make  up  tae 
Data  Base  Control  System. 


DATA  SOUP.CE  A  specialist  in  obtaining  and  interpreting 

SPECIALIST  Amy  documentation  and  other  data  needed  to 

prepare  Air  Defense  System  Modules. 


AIR  SCENARIO 


BRANCHING 


AIR  DEFENSE  SYSTEM 
MODULE 


ENVIRONMENTAL 

STATE  VARIABLE 

An  element  of  an  Errrd-;  dement al  State 

Vector. 

ENVIRONMENTAL 

STATE  VECTOR 

An  array  of  values  representing  conditions 
cr  characteristics  that  may  affect  more 
than  one  operator.  Elements  of  Environmen¬ 
tal  State  Vectors  may  change  dynamically 
miring  a  MOPADS  simulation  to  represent 
changes  in  the  environment  conditions. 

MODERATOR  FUNCTION 

A  rathematical/logical  relationship  vhich 
alters  the  nominal  time  to  perform  an  opera¬ 
tor  activity  (usually  &  Task  Element).  The 
nominal  time  is  changed  to  represent  the 
operator’s  capability 'to  perform  the 
activity  based  on  the  Operator’s  State 
Vector. 

MOPADS  DATA  BASE 

A  computerized  data  base  designed  specifi¬ 
cally  to. support  the  MOPADS  software.  The 
MOPADS  Data  Base  contains  Simulation  Data 
Set(a).  It  coiciiinni  nates  interactively  vith 
MOPADS  Users  during  prs-  and  post-run  data 
specification  and  dynamically  vith  the  SAINT 
softvare  during  simulation. 

MOPADS  MODELER 

An  analyst  who  vill  develop  Air  Defense 
System  Modules  and  modify/ develop  the 

MOPADS  soft  .rare  system. 

MOPADS  USER 

An  analyst  vho  vill  design  and  conduct  simu¬ 
lation  experiments  vith  the  MOPADS  software. 

MSAINT 

(MOPADS/SAINT) 

The  variant  of  SAINT  used  in  the  MOPADS 
system.  The  standard  version  of  SAINT  has 
been  modified  for  MOPADS  to  permit  share¬ 
able  subnetworks  and  more  sophisticated 
interrupts.  The  terms  SAINT  and  MSAINT  a-e 
used  interchangeably  vhen  no  confusion  vill 
result.  See  also,  SAINT. 
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OPERATOR  STATE 
VARIABLE 

One  element  of  an  Operator  State  Vector. 

OPERATOR  STATE 

VECTOR 

An  array  of  values  representing  the  condi¬ 
tion  and  characteristics  of  an  operator  of 
an  Air  Defense  System.  Many  values  of  the 
Operator  State  Vector  •will  change  dynamically 
during  the  course  of  a  M0PAL3  simulation  to 
represent  changes  in  operator  condition. 

OPERATOR  TASK 

An  operator  activity  identified  during 
weapons  system  front-end  analyses. 

SAINT 

The  underlying  computer  simulation  language 
used  xo  model  Air  Defense  Systems  in  Air 
Defense  System  Modules.  SAIST  is  an  acronym 
for  Systems  Analysis  of  Integrated  Networks 
of  Tasks.  It  is  a  veil  documented  language 
designed  specifically  to  represent  human 
factors  aspects  of  man /machine  systems. 

See  also  MSAUJT. 

SIMULATION  DATA  SET 

The  Tactical  Scenario  plus  all  required 
simulation  initialization  and  other  experi¬ 
mental  data  needed  to  perform  a  MOPADS 
simulation. 

SIMULATION  STATE 

At  any  instant  in  time  of  a  MOPADS  simula¬ 
tion  the  Simulation  State  is  the  set  of 
values  of  an  variables  in  the  MOPADS  soft¬ 
ware  the  MOPADS  Data  Base. 

SYSTEM  MODULES 

See  Air  Defense  System  Modules. 

TACTICAL  SCENARIO 

The  Air  Scenario  plus  specification  of 
critical  assets  and  the  air  defense  can-' 
figuration  (number,  type  and  location  of 
veanons  and  the  command  and  control  system) . 
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TACTICAL  SCENARIO 
COMPONENT 

An  element  of  a  Tactical  Scenario,  e.g. , 
if  a  Tactical  Scenario  contains  several 
Q-73's,  each  one  ic  a  Tactical  Scenario 
Component. 

TASK 

See  Operator  Task. 

TASK  ELEMENTS 

Individual  operator  actions  vhir.h,  vhen 
grouped  appropriately,  rake  up  operator 
tasks.  Task  elements  are  usually  repre¬ 
sented  toy  single  SAINT  TASK  nodes  in  Air 
Defense  System  Modules. 

TASK  NODE 

A  modeling  symbol  used  in  the  SAINT  simula¬ 
tion  language.  A  TASK  node  represents  an 
activity;  depending  upon  the  modeling  cir¬ 
cumstances,  a  TASK  node  may  represent  an 
individual  activity  such  as  a  Task  Element, 
or  it  may  represent  an  aggregated  activity 
such  as  an  entire  Operator  Task. 

TASK  SEQUENCING 
MODERATOR 

FUNCTION 

A  mathematical/logical  relationship  vhich 
selects  the  next  Operator  Task  vhich  an 
operator  uill  perform.  The  selection  is 
based  upon  operator  goal  seeking  character¬ 
istics. 
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MOPADS  Abbreviations 

ACC 

ADSM  Character  Code 

DBAA 

Data  Base  Access  Adi 

dress 

DBAP 

Data  Base  Application  Programs 

DBCS 

Data  Base  Control  System 

DL 


DR 


DRAA 


FFSP  Free  Format  Syntax  Processor 


NECC  Kunber  Equi valent  of  a  Character  Code 


Data  List 


Directory- 


Directory  Access  Address 


0 


UI 


User  Interface 


«• 

V 
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I .  PURPOSE 


This  report  documents  the  MOPADS  software  modules  that  imple¬ 
ment  the  MOPADS  User  Interface  (Ul)  and  the  small  main  MOPADS  module 
This  is  a  programmer’s  manual,  not  a  user  manual.  User  instructions 
are  contained  in  Polito  1983(a). 

The  MOPADS  user  interface  provides  interactive  communication 
between  the  user  and  the  MOPADS  data  base.  In  particular,  the  user 
can  perform  five  functions  with  the  user  interface: 

1.  Creating  and  editing  simulation  data  sets. 

2.  Setting  up  data  for  a  particular  simulation 

3.  Examining  statistics  after  a  simulation. 

4.  Creating  and  editing  air  scenario  data. 

5.  Creating  and  editing  new  air  defense  system  modules. 

This  report  documents  the  software  that  implements  all  five 
functions. 

In  addition,  there  is  a  small  main  module  that  directs  program 
control  to  the  user  interface  for  user  interface  sessions  or  to  the 
KSAINT  programs  to  perform  simulations .  Thi3  module  is  also  des¬ 
cribed  here. 

The  MOPADS  software  suffix  for  the  user  interface  is  "I",  and 
for  the  main  module  it  is  "M".  All  of  the  program  names  and  COMMON 
variable  names  in  the  user  interface  end  with  the  letter  I.  Simi¬ 
larly,  all  program  and  COMMON  variable  names  in  the  main  module 
end  with  "K". 


II.  DATA  STRUCTURE  DESCRIPTIONS 


1- 0  THE  USER  INTERFACE 

The  user  interface  has  several  variables  and  arrays  in  labeled 
COMMON  storage  which  are  described  fully  in  Section  VIII.  It  does 
not  have  large  arrays  that  contain  significant  amounts  of  infor¬ 
mation  from  the  data  base.  In  general,  the  UI  stores  only  data 
base  addresses  to  the  information  it  is  currently  operating  on. 
Furthermore,  the  UI  places  the  data  base  in  a  "write-safe"  mode, 
see  Polito  1983(b),  which  means  that  information  is  always  written 
to  the  data  base  file  as  soon  as  it  is  changed.  This  means  that 
it  is  unlikely  that  information  will  be  lost  even  if  the  program 
terminates  abnormally . 

The  user  interface  always  has  a  "current  directory"  which  is 
the  directory  whose  contents  will  be  displayed  if  the  "DIRECTORY" 
command  is  issued,  Polito  1983(a),  and  it  may  have  a  current  data 
list.  It  is  the  addresses  of  these  current  data  base  entries  which 
are  maintained  in  the  UI  data  structure.  Other  auxiliary  data  base 
entries  are  also  saved  as  are  data  specific  to  the  function 
being  performed  in  the  UI. 

2- 0  THE  MAIN  MODULE 

The  main  module  contains  COMMON  storage  for  relatively  global 
data.  For  example  ,  the  unit  numbers  of  all  files  used  by  MOPADS  are 
contained  in  this  labeled  COMMON  area.  A  complete  description  is 
given  in  Section  VIII. 


III.  OVERVIEW  OF  THE  FLOW  OF  CONTROL 


1- 0  THE  USLR  INTERFACE 

Figure  III-l  shows  the  structure  O'*  the  UI.  The  labels  in  the 
boxes  are  actual  subprogram  names.  MO?ADM  is  the  main  program  for 
MOPADS.  It  is  contained  in  the  main  module.  MAINTJI  is  the  single 
entry  point  to  the  UI,  and  it  is  called  whenever  a  user  interface 
session  is  begun. 

Each  of  the  five  UI  functions  discussed  in  Section  I  is  imple¬ 
mented  with  a  "subprocess"  or  small  module  within  the  UI.  Each  sub¬ 
process  has  a  single  entry  point  named  UI1I ,  UI2I,  UI3I,  etc.  In 
addition,  all  subprograms  within  a  subprocess  module  ends  in  the 
appropriate  combination:  "II",  "21",  "31",  etc.  The  subprocesses 
and  their  names  are  shown  below: 

1.  CREATE/EDIT  SIMULATION  DATA  SET 

2.  SET  UP  SIMULATION  RUN  DATA 

3.  EXAMINE  STATISTICS 

1».  CREATE/ EDIT  AIR  SCENARIO 

5-  CPEATE/EDIT  REFERENCE  SYSTEM  MODULE 

Each  subprocess  has  its  own  set  of  commands,  and  each  command 
is  implemented  in  a  separate  subprogram  as  shown  in  the  figure.  Only 
the  examine  statistics  (31)  subprocess  has  been  expanded  to  show 
the  structure.  The  others  are  similar.  Also,  the  basic  data  base 
connands  are  available  from  all  subprocesses.  They  are  implemen¬ 
ted  in  the  same  way  as  the  major  subprocess  commands. 

All  subprocesses  use  the  MOPADS  Free-Format  Syntax  Processor, 
Goodin  &  Polito  1983,  for  command  processing.  Also,  programs  in 
M0PADS/FFIN2,  Polito  1983(c),  MOPADS/DBAP,  Polito  1983(d),  MOPADS/ 
DBCS,  Polito  1983(b),  and  MOPADS /UTIL,  Polito  &  Goodin  1983,  are 
psed  extensively  by  the  UI  programs. 

2- 0  THE  MAIN  MODULE 

The  primary  function  of  the  main  module  is  to  read  all  of  the 
MOPADS  data  cards  and  then  to  call  subroutine  MAINUI  for  user 
interface  sessions  or  subroutines  EATCHM  for  MOPADS  simulations. 

This  structure  is  designed  to  permit  MOPATS  to  be  overlaid  with 
separate  UI  and  simulation  overlays.  In  fact,  MOPADS  can  be  linked 
as  two  separate  load  modules:  simulation  and  UI. 

SUBROUTINE  REALM  ir.  the  main  module  reads  all  of  the  MOPADS 
data  cards.  It  uses  standard  FOETPAN  77  list  directed  input  to  do 
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this,  so  that  M0PADS/FFIN2  programs  are  not  required  in  the  root 
overlay  (if  M1PADS  is  overlaid).  This  ensures  that  the  MSAINT 
simulation  overlay  will  net  contain  unnecessary  programs. 


Basic  Data  Base  Coimand 
Subroutines 


IV.  EXTERNAL  FILE  USAGE 


1- 0  THE  USER  INTERFACE 

The  user  interface  performs  interactive  input  and  output  to  tb'- 
MOPADS  interactive  files,  Polito  1983(e).  Also,  certain  optic" 
allow  the  user  to  print  listings  on  the  MOPADS  line 
printer  file.  All  of  these  files  must  be  opened  with  job  .trol 
language  prior  to  executing  the  UI.  Also,  the  UI  reads  ,ui  writes 
to  MOPADS  data  base  files.  These  files  are  opened  end  closed  with 
calls  to  the  appropriate  MOPADS/DBCS  programs. 

2- 0  THE  MAIN  MODULE 

The  main  module  reads  the  MOPADS  data  cards  from  the  MOPADS 
batch  input  file.  It  opens  and  closes  the  network  data  files  for 
each  system  module  and  copies  their  contents  to  the  MSAINT  network 
input  file  which  it  also  opens.  These  are  the  only  files  used 
by  the  main  module. 
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V. 


SUBPROGRAM  DESCRIPTIONS 


1-0  THE  MAIN  MODULE 

Subprograms  in  the  main  module  have  MOPADS  suffix  "M". 


PROGRAM  HOFADM 

C — MODULE:  MOPADS  MAIN  MODULE 
C— REFERENCE:  MOPADS  VOLUME  5.12 
C — PURPOSE: 

C  THIS  IS  THE  MAIN  PRQGRA.l  FOF  MOPADS.  MOPADS  UILL  READ  UNIT 
C  KUMITMC5)  TO  DETERMINE  IF  THIS  IS  A  BATCH  SIMULATION  OR 

C  AN  INTERACTIVE  USER  INTERFACE  JOB.  A  FILE  MUST  HAVE 

C  BEEN  PRE-ASSIGNED  TO  KUNITM<5). 


SUBROUTINE  BATCHM 
C — MODULE:  MOPADS  MAIN  MODULE 
C — REFERENCE :  MOPADS  VOLUME  5.12 
C--PURPOSE: 

C  BATCHM  UILL  INITIATE  BATCH  SIMULATION  PROCESSING.  IT  UILL 
C  PERFORM  NEEDED  INITIALIZATION  AND  CALL  SUBROUTINE  MAIN  UHJCH 
C  IS  THE  SINGLE  ENTRY  POINT  TO  MSAINT. 


BLOCK  DATA  BLOCKM 
C— MODULE:  MOPADS  MAIN  MODULE 
C— REFERENCE:  MOPADS  VOLUME  5.12 
C — PURPOSE: 

C  TO  INITIALIZE  VARIABLES  IN  THE  MAIN  MOPADS  MODULE. 

C 


SUBROUTINE  GTRUNM(IELL,RUND, LABEL, ACN , IERR , « ,* ) 

C— MODULE:  MOPADS  MAIN  MODULE 
C--KEFERENCE:  MOPADS  VOLUME  5.12 
C — PURPOSE: 

C  GTRUNM  UILL  RETURN  CONTENTS  OF  THE  RUN-DATA"  DATA  LIST.  IT 

C  UILL  RETURN  EITHER  THE  10  DATA  U0RD5  OR  A  (LABEL, ACN) 

C  PAIR  DEPENDING  UPON  THE  VALUES  OF  IELL . 
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C- - INPUT  PARAMETERS: 

C  I ELL  -IF  IELL.LE.O,  GIRUNM  RETURNS  THE  FIRST  10  UORDS  OF 
C  THE  'RUN-DATA'  DATA  LIST.  RUNDMO)  UILl  BE  THE 

C  NUMBER  OF  CRITICAL  ASSETS  PROTECTED  £Y  1  HE  AD 

C  CONFIGURATION.  SEE  NOPABS  VOL.  5.1?  FDR  DEFINITIONS 

C  OF  THE  OTHER  VALUES. 

C 

C  IF  IELL.GT.O,  THEN  “LABEL"  IS  THE  LABEL  OF  A  CRITICAL 

C  ASSET  AND  "ACN“  IS  THE  ACN  OF  THE  UNIT  ASSIGNED  TO 

C  PROTECT  IT.  THE  IELL-TH  PROTECTED  ASSET  IS  RETURNED. 

C  THE  MAX  NUMBER  OF  ASSETS  IS  FOUND  FROM  RUND(IO)  FOR  A 

C  CALL  WITH. IELL=0. 

C — OUTPUT  PARAMETERS: 

C  RUND( 1 0 » —OUT PUT  ARRAY  FOR  IELL.LE.O.  NO!  USED  IF  IELL.GT.O 

C  LABEL- (CHARACTERS)  OUTPUT  LABEL  OF  THE  IELL-TH  PROTECTED 

C  SITE  IF  IELL.GT.O.  NOT  USED  IF  IELL.LE.O. 

C  ACN-ACN  OF  THE  AD  UNIT  PROTECTING  THE  SITE  SPECIFIED  IN 
C  LABEL  IF  IELL.GT.O.  NOT  USED  IF  IELL.LE.O. 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  NE.O-BB  ERROR  CODE 

C — ALTERNATE  RETURNS: 

C  1 -USED  ONLY  IF  IELL.GT.O  AND  IELL.GT.THE  TOTAL  NUMBER  OF 

C  PROTECTED  SITES. 

C  ?-B  ERROR(IERR.NE.O) 


SUBROUTINE  G T S D S h ( * ) 

C--MODULE:  MOPADS  MAIN  MODULE 
C—REFERENCE:  MOPADS  VOLUME  5.12 
C — PURPOSE: 

C  GTSDSM  UILL  LOCATE  THE  SIMULATION  DATA  SET  AND  TACTICAL 

C  SCENARIO  SPECIFIED  FOR  A  BATCH  JOB.  II  UILL  ALSO  CREATE 

C  THE  STATISTICS  DIRECTORY  FOR  THE  JOB  IN  THE  DATA  BASE. 

C  GTSDSM  USES  SOME  ROUTINES  FROM  THE  USER  INTERFACE  TO 
C  DO  THIS 

--ALTERNATE  RETURNS: 

!.  1-PROCESSING  FAILED.  ABORT  JOB 


SUBROUTINE  INITH 
C — MODULE :  MOPADS  MAIN  MODULE 
C—REFERENCE:  MOPADS  VOLUME  5.12 
'•—PURPOSE: 

INI TM  INITIALIZES  THE  MOPADS  MAIN  HODULL. 


C 


o  o  o 


SUBROUTINE  READMt  I T  Yr'E , * ) 

C — MODULE:  MOPADS  MAIN  MODULE 
C — REFERENCE:  MOPADS  VOLUME  5.12 
C—PURPQSE: 

C  READM  UILL  READ  KUNITM<5>  TO  DETERMINE  IF  THIS  IS  A  BATCH 
C  CR  INTERACTIVE  JOS.  KUNITH(5>  MUST  HAVE  BEEN  PREVIOUSLY 
C  ASSIGNED  TO  THE  INPUT  FILE.  MOPADS  DOES  NOT  EXPLICITLY 
C  OPEN  KUNITM(5) . 

C  READING  FROM  KUNITM15)  IS  DONE  UITH  LIST  DIRECTED  INPUT. 

THE  ENTIRE  INPUT  FILE  IS  READ.  READM  OPENS  THE  DATA 
BASE  FILE  IF  THIS  IS  A  BATCH  JOB,  BUT  IT  DOES  NOT 
LOCATE  THE  SIMULATION  DATA  SET  OR  TACTICAL 
C  SCENARIO. 

C 

C--OUTPUT  PARAMETERS: 

C  IT YPE- JOB  TYPE 

C  1-PATCH  JnB  OF  SAINT 

C  2-USER  INTERFACE  SESSION 

C  —  ALTERNATE  RETURNS: 

C  •  -ERROR  ON  INPUT  FILE 


ft--.* 
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2-0  USER  IHTERFACE  UTILITIES  ASL  BASK  DATA  BASE  PROGRAMS 


Several  programs  in  the  user  interface  provides  utility 
functions'  for  other  user  interface  modules.  These  programs  end  with 
the  single  suffix  "I".  The  basic  data  base  programs  that  implement 
commands  common  to  all  user  interface  subprocesses  end  in  the  suffix 
”01".  Both  of  these  collections  of  programs  are  included  in  this 
sectioa. 


SUBROUTINE  HAINUI 
C--R0DULE:  ROPADS/UI 
C— REFERENCES  ROPADS  VOL.  5.12 
C~  PURPOSE! 

C  AAIMUI  IS  THE  SINGLE  ENTRY  POINT  TO  THE  USER  INTERFACE  HODULE. 
C  BLOCK  DATA  PROGRAM  BLUCKI  RUST  BE  LOADED  UITH  K.1S  NODULE. 

C  UNITS  KUNITNt?)  ARB  KUNlTfllt?)  RUST  HAVE  BEEN 

C  ASSIGNED  TO  THE  TERMINAL  FOR  INTERACTIVE  I/O 
C  UITH  JOB  CONTROL  LANGUAGE  PRIOR  TO  EXECUTING 

C  ROPADS. 


SUBROUTINE  ABORTI 
C--RODULES  HOPADS/UI 
C--REF£RtNCEs  ROPADS  VOL.  5.12 
(.--PURPOSES 

C  TO  PRINT  THE  "CQHRAND  ABORTED  MESSAGE” 

C 


BLOCK  JATA  BLOCKI 
C— RODULEs  ROPADS/UI 
C--REFERENCE:  ROPADS  VOL.  5.12 
C--PURPOSE: 

C  BLOCKI  INITIALIZES  LABELED  COMMON  IN  THE  USER  INTERFACE. 


SUBROUTINE  CPROC1 
C--RODULE:  HOPADS/UI 
C—REFERENCEs  ROPADS  VOL.  5.12 
C— PURPOSES 

C  CPROCI  IS  THE  PROGRAR  UHICH  SELECTS  UHiCH  SUBPROZESS  THE  USER  UIL 

ENTER. 

C 


SUBROUTINE  FNSRI ( NDB , IPRT .LABEL r IERR,* ,* ) 

C — MODULE:  HOPADS/UJ 
C— REFERENCE:  ROPADS  VOL.  5.12 
C— PURPOSES 

C  FNSRI  WILL  LOCATE  A  SPECIFIED  REFERENCE  ADSH  IN  THE 

C  "REFERENCE  ADSrt"  DF  ON  THE  SPECIFIED  DB  AND  HAKE  IT 

C  THE  CURRENT  JR. 


C— INPUT  PAkAHElERS: 

C  NDB-PATA  i(ASm-UQRKING,2~AEFERENCE) 

C  IPRT-PR INT  OPTION 

C  '-PRINT  ERROR  MESSAGE  IF  ADSH  NOT  PRESENT 

C  2-DO  NOT  PRINT 

C  LABEL-CHARACTER  LABEL  OF  THE  ADSH  TO  F INI) 

C— OUTPUT  PARAHETERS: 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  .NE.O-D8CS  ERROR  CODE 

C— ALTERNATE  RETURNS: 

C  1 -LABEL  ADEN  NOT  FOUND 

C  2-IERR.NE.O 


SUBROUTINE  1NITI 
C—flODULE:  HQPADS/UI 
C—REFERENCE:  NOPADS  VOL.  5.12 
C--PURPQSE: 

C  INI T I  INITIALIZES  THE  NOPADS  USER  INTERFACE 

C 


FUNCTION  KHNDI (CMNDS,NCHD,NDEX) 

C— NODULE:  NOPADS/UI 
C — REFERENCE:  NOPADS  VOL.  5.12 
C  —  PURPOSE ; 

C  KHNDI  READS  THE  NEXT  COHHAND  AND  IDENTIFIES  IT.  IF  IT  IS  A  BASIC 

C  DB  COHHAND,  IT  PROCESSES  IT. 

C 

C — INPUT  PARAHETERS: 

C  CHNDSfNCHD 1-CHAR ACTER  ARRAY  OF  COHHANDS 

C  NCHD-THE  NUH6ER  OF  COHHANDS  AVAILABLE 

C  NDEX(NCHD)-INDLX  ARRAY  FOR  CHNDS  FOR  USE  WITH  IBFCU.  ON  FIRST 
C  CALL  SET  NDEXI1 )=0 

C 

C— OITPUT  PARAHETERS: 

C  KHNDI  =0-IHPlIES  COHHAND  UAS  NOT  IDENTIFIED  OR  UAS  PROCESSED  BY 
C  KHNDI.  PROHFT  FOR  NEXT  COHHAND. 

C  =I-PROCESS  COHHAND  I 

C  =-I  PROCESS  HELP  COHHAND  FOR  COHHAND  I 

C 
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SUBROUTINE  MNCUl(NDD) 

C— MODULE:  HOPA0S/UI 

C--SEF ERENCE:  MQPADS  VOL.  5.12 

C— PURPOSE; 

C  ftttCUI  U1LL  RAKE  THE  RAIN  DIRECTORY  CURRENT  IN  THE 

C  USER  INTERFACE  WITH  NO  CURRENT  DL. 

C— INPUT  PARAflETERSt 

C  NDI-DAI A  I ASEU-UORK  INC  ,2-REFERENCE) 


SUBROUTINE  PLINKKIOPT.IERR) 

C — NODULE:  ROPAOS/UI 
C— REFERENCE:  ROPADS  VOL.  5.12 
C— PURPOSE: 

C  TO  HAXE  THE  OUNER  DIRECTORY  OF  THE  CURRENT  DIRECTORY  THE  NEU 
C  CURRENT  DIRECTORY.  IT  IS  CALLED  AS  A  RESULT  OF  THE  HOPADS 

C  PUNK  COMMAND. 

C 

C— PROMPTS 

C  DB-DATA  BASE-UORK I NG /REFERENCE 

C 

C— INPUT  PARAMETERS: 

C  IOPT-COMHAND  OPTION 

C  O-PERFORH  COMMAND 

C  1-HELP  ISSUED 

C — OUTPUT  PARAMETERS: 

C  IERR-ERRQR  CODE 

C  O-NO  ERROR 

C  .NE.O-DB  ERROR  CODE  IF  CANNOT  DO  COMMAND 

C 
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SUBROUTINE  ClOSJJ  <IOPT,IERR> 

C 

C ••flODUL E  t  MOPADS/USER  INTERFACE 
C**REF£R£NCE:  HUPADS  VOLUME  3.12  DF 


C 


C**PURP03E; 

C 

c 

c 

c 

c 


THIS  SUIROUT IKE  IS  USED  TO  CLOSE  A  DATA  IASE  FILE. IT  IS 
CALLED  IT  ISSUING  A  "CLOSE*  COMMAND  IN  THE  USER  INTERFACE. 
PROMPTS  FOR  THE  "CLOSE"  COMHhND: 

DB»DATA  BASE  TYPE-UOKK1NG/REFERENCE 
STATUS«KEEP/DELETE 


C»«INPUT  PARAMETERS: 

C 

C 

C— output  PARAMETERS; 
C 

c 

c 

c 


IOPTxCOHHAND  OPTION 

«0  PERFORM  COMMAND  LOGIC 

•1  HELP  COMNAND  ISSUED  FOR  THIS  COMMAND 

IERR-ERROR  CODE 
O-NO  ERROR 

.NE.O-DBCS  ERROR  CODE  IF  CANNOT  DO  COMMAND 


SUBROUTINE  CURROI(IOPT,IERR> 

C 

C**HODUL£ ;  MOPADS/USER  INTERFACE 
DEREFERENCE:  MGPADS  VOLUME  5.12  DF 
C 


C**F'URPQSE  s 
C 

c 
c 
c 
c 
c 
c 
c 
c 

C**INPUT  PARAMETERS: 
C 

c 

C — OUTPUT  PARAMTERS: 

C 

C 


THIS  SUBROUTINE  IS  USED  TO  DISPLAY  THE  IDENTITY  OF  THE 
CURRENT  DIRECTORY  OR  DATA  LIST. IT  IS  CALLED  BY  ISSUING 
A  "CURRENT"  COMMAND  IN  THE  USER  INTERFACE. 

PROMPTS  FOR  THE  "CURRENT"  COMMAND: 

DB=DATA  BASE  TYPE-UORKING/REFERENCE 
DISPLAY=UHAT  DOES  THE  USER  UANT  DISPLAYED 
LAPEL/ID/ALL  INFO 
TYPE=TYPE  OF  ENTRY  TO  DISPLAY 
DIRECTORY/DAT A-LIST/ALL 


IOPT=COHHAND  OPTION 

=0  PERFORM  COMMAND  LOGIC 

=1  HELP  COMMAND  ISSUED  FOR  THIS  COMMAND 

IERR-ERRGR  CODE 
O-NO  ERROR 

.NE.O-DBCS  ERROR  CODE 
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SUBROUTINE  DBCOI  ( CONAND ,  1CMD,  IERR ,  *  > 

C~  MODULE:  MOPADS/UI 

C— REFERENCE!  HOPADS  VGL.  5.12 

C--PURP0SE! 

C  DBCOI  WILL  DETERMINE  IF  A  COMMAND  IS  ONE  OF  THE  LOU  LEVEL  DB 

C  COMMANDS  AVAILABLE  AT  ALL  LEVELS.  IP  SO  IT  UILL  PROCESS  THE 

C  COMMAND. 

C 

C— INPUT  PARAMETERS! 

C  COHAND-CHARACTER  VARIABLE  TO  COMPARE  UITH  LOU  LEVEL  COWHANDS. 

C— OUTPUT  PARAMETERS! 

C  ICMD-  «-t  COMMAND  IS  AMBIGUOUS 

C  «  0  COMMAND  NOT  FOUND 

C  «  I  COMMAND  IS  THE  I-TH  LOU  LEVEL  DB  COMMAND 

C  1ERR-ERRCR  CODE 

C  O-NO  ERROR  OR  ICMD.LE.O 

C  DBCS  ERROR  CODE  IF  LOU  LEVEL  COMMAND  COULD  NOT  BE  PERFORMED 

C — ALTERNATF  RETURNS: 

C  1 -ICMD.LE.O 


SUBROUTINE  DEPOOI  (IQPTf IERR) 

C 

C»*M0DUtE:  MOPADS/USER  INTERFACE 
PREFERENCE:  HOPADS  VOLUME  5.12  DF 
C 

^♦PURPOSE*  THIS  SUBROUTINE  IS  USED  TO  SET  VALUES  IN  THE  ELEMENTS  OF 
C  THE  CURRENT  DftTA-LIST . IT  IS  CALLED  BY  ISSUING  A  “DEPOSIT'' 

COMMAND  IN  THE  USER  INTERFACE. 

PROMPTS  FOR  THE  "DEPOSIT"  COMMAND: 

DB=DATA  BASE  TYPE-UORKING/REFERENCE 

♦♦INPUT  PARAMETERS:  IOPT=CCMMAND  OPTION 

=0  PERFORM  COMMAND  LOGIC 

=1  HELP  COMMAND  ISSUED  FOR  THIS  COMMAND 

— OUTPUT  PARAMETERS: 

IERR-ERROR  CODE 
C  O-NO  ERROR 

C  .NE.O-DB  ERROR  CODE 
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SUBROUTINE  DIROl ( IHPT , IEPR5 
C 

C**MODULE:  MOPADS/UScR  IMTERf ACE 
C»*REFEP£NC£:  NOPADS  VOLUNE  5.1?  DF 
C 


CMPURPOSE; 

C 

c 
c 
c 
c 
c 
c 
c 

CMINPUT  PARANETERSj 

c 

c 

CMOUTPUT  PARAMETERS: 

c 

c 

c 

c 


THIS  SUBROUTINE  IS  USED  TO  LIST  SELECTED  CONTENTS  OF  THE 
CURRENT  DIRECTORY  ON  THE  UORKIMG  OR  REFERENCE  DATA  BASE. 
IT  IS  CALLED  BY  ISSUING  A  "DIRECTORY*  COMMAND  IN  THE  USER 
INTERFACE. 

PROMPTS  FOR  THE  "DIRECTORY"  COMMAND: 

TYPE-TYPE  OF  CONTENTS  USER  WANTS  LISTED 
DIRECTORY/DAT  A-LIST/ ALL 
DBrDATA  BASE  TYPE-UORKING/REFERENCE 


IOPT«COHMAND  OPTION 

>0  PERFORM  COMMAND  LOGIC 

■1  HELP  COMMAND  ISSUED  FOR  THIS  COMMAND 


IERR-DB  ERROR  CODE 
O-NO  ERROR 
.NE.O-DB  ERROR  CODE 


SUBROUTINE  EDDLCI (ND8, I0F1 ,I0F2,IDBAA,IERR,*) 

C— MODULE:  MOPADS/UI 
C — REFERENCE:  MOPADS  VOL.  5.12 
—PURPOSE: 

EDDLOI  PROMPTS  THE  USER  FOR  EDITS  OF  DATA  LISTS  ORGANIZED  LIKE 
THE  OPERATOR  STATE  VECTORS.  THAT  IS,  THE  COLUMNS  IF01  YQ  IF02  ARE 
ELIGIBLE  TO  BE  EDITED  AND  THESE  ELEMENTS  ARE  NUHBLREDIFROM  THE 
USER'S  STANDPOINT)  FROM  1  (CORRESPONDING  TO  IF01)  TO 
IF02-IF01  (CORRESPONDING  TO  IFC2).  THE  USER  MAY  CHANGE  THE 
C  VALUES  OR  LABELS  OF  THESE  ELEMENTS.  THE  DL  MUST  BE  A  REAL,  2-D 
C  (UITH  2  ROUS)  DL.  - 

C 

C — INPUT  PARAMETERS: 

C  NDB-DATA  BASEL  1 -U0RK1NG, 2-REFERENCE ) 

C  IF01 -FIRST  COLUMN  ELIGIBLE  TO  BE  CHANGED 
C  IF02-IF02  IS  THE  LAST  COLUMN  ELIGIBLE  TO  BE  CHANGED 
C— INPUT/OUTPUT  PARAMETERS: 

C  IDBAA ( 2 ) -DBAA  OF  THE  DL 
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C— OUTPUT  PARAMETERS* 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

O  . NE.O-DBCS  ERROR 

C--ALTEKHATE  RETURNS* 

C  1-IERR.NE.O 


SUBROUTINE  EXAHOI  UOPT.IERR) 


CmhODULE*  HOPADS/USER  INTERFACE 
^♦REFERENCE*  NOPADS  VOLUME  5.12  DF 
C 

THIS  SUBROUTINE  IS  USED  TO  DISPLAY  VALUES  IN  THE  ELEMENTS  0 
THE  CURRENT  DATA-LIST . IT  IS  CALLED 
COMMAND  IN  THE  USER  INTERFACE. 

PROMPTS  FOR  THE  "EXAMINE*  COMMAND* 

DB*DATA  BASE  TYPE-UORKING/REFERENl|E' 

HEADER=DISFLAT  HEADER  INFO-YES/NO 
DEVICE'UHERE  TO  DISPLAY -TERM INAL /PR INTER 


C**PURPOSE* 

C 
C 
C 
C 
C 
C 
C 

C**INPUT  PARAMETERS* 

C 

C 

C— OUTPUT  PARAMETERS* 
C 
C 
C 


V 


ISSUING  A  "EXAMINE" 


.1 


IOPT ^COMMAND  OPTION 

=0  PERFORM  COMMAND  LOGIC 

*1  HELP  COMMAND  ISSUED  FOR  THIS  COMMAND 

IERR-ERROR  CODE 
O-NO  ERROR 
•NE.O-DB  ERROR  CODE 


SUBROUTINE  OPENOI  (IOPT.IERR) 

C 

C**MODULE*  MOPADS/USER  INTERFACE 
C**REFERENCE;  MOPADS  VOLUME  5.12  DF  ' 

C  (■ 

C**PURPOSE*  THIS  SUBROUTINE  IS  USED  TO  OPEN  A  DATA  BASE. IT  IS  CALLFD 
BY  ISSUING  AN  "OPEN"  COMMAND  IN  THE  USER  INTERFACE. 
PROMPTS  FOR  THE  "OPEN"  COMMAND: 

FILE=FILE  NAME  FOR  THE  DATA  BASE 
STATUS=STATUS-OLD/NEU 
DB=DATA  BASE  TYPE-UORKING/REFERENCE 
C  MAXRECORD=MAXIMUM  NUMBER  OF  RECORDS  IN  DATA  BASE 

C 

C** INPUT  PARAMETERS!  IOPT=COHMAND  OPTION 
C  =0  PERFORM  COMMAND  LOGIC 

C  =1  HELP  COMMAND  ISSUED  FOR  THE  COMMAND 
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C~ OUTPUT  PARAHTERS<  IERR-ERRDR  CODE 
C  0-X0  ERROR 

C  .NE.O-DBCS  ERROR  CODE  IF  CANNOT  00  COMMAND 

C 


SUBROUTINE  SELEOI  UOPT.KRR) 

C 

C<<HODULE<  HOPADS/USER  INTERFACE 
C<<REFERENCE<  HOPADS  VOLUHE  5.12  DF 
C 


C  <  *  PURPOSE  s 
C 
C 
C 
C 
C 
C 
C 
C 
C 

c 
c 
c 
c 

C«INPUT  PARAHETERS< 
C 
C 
C 

C—OUTPUT  PARAMTERS< 
C 

c 

c 

c 


THIS  SUBROUTINE  IS  USED  TO  SELECT  THE  CURRENT  DIRECTORY  OR 
DATA-LIST  FROH  THOSE  ON  THE  CURRENT  DIRECTORY. IT  IS  CALLED 
BY  ISSUING  A  "SELECT"  COHHAND  IN  THE  USER  INTERFACE. 
PROMPTS  FOR  THE  "SELECT*  COHHAND< 

DB«DATA  BASE  TYPE-UORKING/REFERENCE 
TYP£=TYPE  OF  ENTRY  BERG  SELECTED 
DIRECTORY/D AT A-LIST 

POSITIONED I RECTORY  POSITION  OF  THE  ENTRY  BEING  SELECTED 
LABELeLABEL  OF  THE  ENTRY  BEING  SELECTED 
ID»ID  OF  THE  ENTRY  BEING  SELECTED 
NOTE<THE  USER  DILL  RESPOND  TO  ONLY  ONE 
PROMPTS  AND  KILL  TAKE  THE  DEFAULT 
TUO. 


OF  THE  LAST  THREE 
VALUE  ON  THE  OTHER 


IQPT=COHMAND  OPTION 

=0  PERFORM  COMMAND  LOGIC 

*1  HELP  COMMAND  ISSUED  FOR  THE  COMMAND 


IERR-ERROR  CODE 
O-NO  ERROR 
•NE.O-DB  ERROR 
DONE 


CODE  IF  COMMAND  COULD  NOT  BE 


SUBROUTINE  TERHOI ( IOPT,  IERR) 

C 

C<<MCDULE<  MQPADS/USER  INTERFACE 
C<<REFERENCE<  HOPADS  VOLUME  5.12  DF 
C 

C<<PURPOSE<  THIS  SUBROUTINE  IS  USED  TO  TERMINATE  A  TERMINAL  SESSION. 

IT  MILL  CLOSE  ALL  OPEN  DATA  BASES  UITH  STATUS=KEEP. IT  IS 
CALLED  BY  ISSUING  A  “TERMINATE"  COMMAND  IN  THE  USER 
INTERFACE. 

C  PROMPTS  FOR  THE  "TERMINATE"  COMMAND: 

C  NO  PROMPTS 
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C--INP1T  PARAMETERS: 

C  IOPT-COMMAND  OPTION 

C  0-00  COMMAND 

C  1-HELP  COMMAND 

C— OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  .ME. 0-08  ERROR  CODE  IF  CANNOT  DO  COMMAND 

C 
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3-0  II  -  CREATE/EDIT  SIMULATION  DATA  SET 

Tne  program  in  the  Create/Edit  S imitation  Data  Set  subproeess 
vhich  end  with  the  suffix  "II”  are  in  this  ser  .ion. 


h 


w 

% 


s 


£ 

if* 

$ 


y 

V 


S- 
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SUBROUTINE  UI1IUOPT) 

C--MODULE:  MOPAl'S/UI 
C — REFERENCE :  flOKADS  VOL.  5.12 
C— PURPOSES 

C  UI1I  IS  THE  ENTRY  POINT  TO  THE  “CREATE/EDIT  SIMULATION  DATA 

C  SET"  SUBPROLESS 

C 

C  —  INPUT/OUTPUT  PARAMETERS: 

C  JOPT-  ON  INPUT  IT  IS  J.  IF  ON  OUTPUT  IT  IS  ZFRO,  A  TERMINATE 

C  COMMAND  UILL  BE  EXECUTED. 


SUBROUTINE  ADD1 I ( IOPT , IERR ) 

C—  MODULE:  MOFADS/UI 
E — REFERENCE:  HQPADS  VOL.  5.12 
C — PURPOSE: 

C  ADO  1 1  UILL  PERFORM  AN  ADD  COMMAND  IN  THE  “CREATE/EDIT 

C  SIMULATION  DATA  SET  SUBPROCELS 

C — INPUT  PARAMETERS: 

C  IOPT-OPTION 

C  O-DO  COMMAND 

C  1-DO  HELP  COMMAND 

C--OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  .NE.O-DB  ERROR  CODE 


i? 

$ 


p  , 

b  'i 


SUBROUTINE  CHAN1 I (IOPT, IERR)  f/; 
C — MODULE:  MOPADS/UI  •>' 
>- REFERENCE:  MOPADS  VOL.  5.12 

C — PURPOSE :  ^3 
C  CHAN1I  UILL  PERFORM  A  CHANGE  COMMAND  IN  THE  CREATE/EDIT  »>: 
C  SIMULATION  DATA  SET  SUBPROCESS.  ^ 
C--INPUT  PARAMETERS: 

C  IOPT-OPTION 
C  O-PERFORM  COMMAND 

C  1 -PERFORM  HELP  COMMAND  ~ 
C  —  OUTPUT  PARAMETERS:  >; 
C  IERR-ERROR  CODE  O 
C  .  O-NO  ERROR  Sj 
C  .NE.O-DBCS  ERROR 


v 

N* 
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SUBROUTINE  CHFV1HJERR,*,*) 

C — MODULE :  MOPADS/UI 

C — REFERENCE:  MOPADS  VOL.  5.12 

C--PURPOSE  i  i 

C  CHFV1I  ALLOWS  THE  USER  TO  EDIT  THE  F t ELD-OF-VIEU  DATA  LIST  OF 
C  CURRENT  WORKING  ADSrt. 

C — OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  .NE.O-D8CS  ERROR  CODE 

C — ALTERNATE  RETURNS: 

C  1-COMMAND  CANCELLED 

C  2-IERR.NE.O 


TINE  CRFV1I(NACCfNACN,LABl12,IDRAArIERR,*) 

QPADS/UI  i 

:  MOPADS  VOL.  5.12 

C— PURPOSE: 

C  CRFV1I  CREATES  THE  FIELD  OF  VIEU  DL  fOR  CODE  12  DIRECTORIES. 
C  —  INPUT  PARAMETER:  j 

C  NACC-NECC(ACC)  OF  THE  OWNER  DIRECTORY 

C  NACN-THE  ACN  OF  THE  OWNER  DIRECTORY 
C  LABL 12- (CHARACTER)  LABEL  OF  THE  QUHEFt  DR 

C— INPUT/OUTPUT  PARAMETERS: 

C  IDRAA ( A ) -DRAA  OF  THE  OWNER  DIRECTORY 

C  — OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

c  !ne.o-dbcs  ERROR  CODE 

C  — ALTERNATE  RETURNS: 

C  1-IERR.NE.O 


SUBROUTINE  CRTR1 1 <NACC,LABL1 2 . IDRAA f IERR , * ) 

C--MODULE:  MOPADS/UI 
C— REFERENCE:  MOPuDS  VOL.  5.12 
C— PURPOSE: 

C  CRTR1I  WILL  CREATE  THE  TRACK-DATA(TRD)  DATA  LIST  OF  A 

C  CODE  12  DIRECTORY 
C  —  INPUT  PARAMETERS: 

C  NACC-NECC ( ACC )  OF  THE  OWNER  DIRECTORY 

C  LABL12— (CHARACTER)  LABEL  OF  THE  UUNEft  DIRECTORY 


SUBRO 
C— MODULE: 

C  —  REFERENC 


C— INPUT/QUTPM7  PARAMETERS: 

C  I DRAA < 4 ) -DRA A  OF  THE  OUNER  DR 

C— OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  O-KO  ERROR' 

C  .NE.O-DBCS  ERROR 

C— ALTERNATE  RETURNS: 

C  1-IERR.NE.O 


SUBROUTINE  DELEI  I ( IOPTr IERR) 

C— MODULES  NOPADS/UI 
C — REFERENCE:  MOPADS  VOL.  5.12 
C — PURPOSE: 

C  DELEI  I  UILL  PERFORM  THE  "DELETE"  COMMAND  IN  THE  "CREATE/EDIT 

C  SIMULATION  DATh  SET"  SUBPROCESS 

C 

C  — INPUT  PARAMETERS: 

C  IOPT-OPTION 

C  O-PERFORM  COMMAND 

C  1 -PERFORM  HELP  COMMAND 

C-OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  .NE.O-DBCS  ERROR 


SUBROUTINE  FSDS1 I ( IOPT , ION U, IERR,* ,* ) 

C  — MODULE:  NOPADS/UI 
C— REFERENCE:  MOPADS  VOL.  5.12 
C— PURPOSE: 

C  FSDS1I  UILL  LOCATE  A  PARTICULAR  S.'^ULATION  DATA  SET  IN  THE 
C  MASTER  DIRECTORY  OR  RETURN  AN 
C  INDICATION  THAT  IS  IS  HOT  PRESENT. 

C  IF  FOUND,  IT  UILL  LOAD  ITS  DRAA  IN  1URF1 I  (1,1),  ITS  COMMAND 

C  AND  CONTROL  DIRECTORY  IN  I'D R F 1 1 < 1 f 2 >  AND  ITS  COPY  COUNTER 

C  DBAA  IN  I DRF (1,3). 

C  IT  UILL  OPTIONALLY  MAKE  THE  SIMULATION  DATA  SET  CURRENT. 

C  — INPUT  PARAMETERS: 

C  IOPT-OPTION 

C  1-DO  NOT  MhKE  THE  SIMULTION  DATA  SET  CURRENT 

C  2-DO  MAKE  THE  SIM-iAIA-SET  CURRENT 

C  IDNO-SIMULAT ION  DATA  SET  TO  FIND 
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C — OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 
C  O-NO  ERROR 

C  .NE.O-DBCS  ERROR 

C— ALTERNATE  RETURNS: 

C  1-SIMULATION  DATA  SET  "ID"  NOT  FOUND 

C  2-IERR.NE.O 


SUBROUTINE  FSM1 I(IPRTtLABEL,IDRAA,!ERR,*,*) 

C— MODULE:  MOPADS/UI 
C — REFERENCE:  NOPADS  VOL.  5.12 
C— PURPOSE: 

C  FSA1I  UILL  LOCATE  A  SPECIFIED  WORKING  ADSH  IN  THE 
C  CURRENT  WORKING  DR  ON  THE  WORKING  DB. 

C — INPUT  PARAMETERS: 

C  IPRT-PRINT  OPTION 

C  1 -PRINT  ERROR  MESSAGE  IF  ADSM  NOT  PRESENT 

C  2-DO  NO  I  PRINT 

C  LABEL-CHARACTER  LABEL  OF  THE  ADSM  TO  FIND 

C — OUTPUT  PARAMETERS! 

C  IDRAAHJ-DRAA  OF  THE  UORKING  ADSM.  ZERO  IF  NOT  FOUND. 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  .NE.O-DBCS  ERROR  CODE 

C— ALTERNATE  RETURNS: 

C  1 -LABEL  ADSM  NOT  FOUND 

C  2-IERR.NE.O 


SUBROUTINE  FUSD1 I< !ERR, «,♦) 

C — MODULE:  HQPAD5/UI 
C— REFERENCE:  MOPADS  VOL.  5.12 
C— PURPOSE: 

C  FUSD1I  UILL  SEARCH  UP  THE  DIRECTORY  TREE  FROM  THE  CURRENT 
C  DR  TQ  FIND  THE  SIMULATION  DATA  SET  DR.  THEN  IT  UltL  SET 

C  IDRF 1 1 ( - r 1 ) =PRAA  OF  THE  SIMULATION  DATA  SET 

C  IDRF1H-,2)=C0MMAND  AND  CONTROL  DR 

C  IDRF1I(-,3)-CQPT  COUNTER  DL 

C — OUTPUT  PARAMETERS? 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  .NE.O-DB  ERROR  CODE 

C — ALTERNATE  RETURNS: 

C  1 -HO  SIM.  DATA  SET  FOUND 

C  2-IERR.NE.O 


* 

> 


v 
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SUBROUTINE  GT VU 1 1 < I VUR , 1 1 ,I2,IDRAA,DLS,NDLS,IERr!,*,*> 

C— NODULE:  H0PAD3/UI 
C — REFERENCE :  NOPADS  VOL.  5.12 
C— PURPOSE: 

C  GTVU1I  U ILL  RETURN  PORTIONS  OF  THE  A  ViEUER  RQU  IN  A  FIELD 

C  OF  VIEU  DATA  LIST.  GTVU1I  DOES  NO  CHECKING  ON  Tl!F.  INPUT 

C  PARANETERS  FOR  VALIDITY. 

C— INPUT  PARAMETERS: 

C  IVUR-VIEUER  NUMB£R(ACTUALLY.  THE  RQU  NUMBER) 

C  11,12-GET  COLUMN  II  TO  12 

C— INPUT/OUTPUT  PARAMETERS: 

C  IBRAAH>-DRAA  OF  THE  'FV'  BL 

C— OUTPUT  PARAMETERS: 

C 

C  DLS1NDLSJ-OUTPUT  .ARRAY.  ELEMENTS  II  TO  12  UILL  BE  CHANGED 
C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  .NE.O-DBCS  ERROR  CODE 

C— ALTERNATE  RETURNS: 

C  1-IERR=6.  DLS  NOT  CHANGED.  ROU  IVUR  DOES  NUT  EXIST. 

C  2-IERR.NE.i. AND. 1ERR.NE  .0 


SUBROUTINE  INSR1 I ( IOPT , IERR) 

C — MODULE:  MCPADS/UI 
C — REFERENCE:  MOPADS  VOL.  5.12 
C— PURPOSE: 

C  INSR1I  UILL  PERFORM  THE  "INSERT"  COMMAND  IN  THE  "CREATE/EDIT 
C  SIMULATION  DATA  SET"  SUBPROCESS. 

C 

C  —  INPU T  PARAMETERS: 

C  IOPT-OPTION 

C  O-DO  COMMAND 

C  1-DO  HELP  COMMAND 

C— OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  .NE.O-DBCS  ERROR  CODE 


SUBROUTINE  ftXSOl I (NECA, IDRAA.NSEQ) 

C— MODULE:  MOPADS/UI 

C — REFERENCE:  MOPADS  VOL.  5.12 

C—PURPOSE: 

C  NXSQ11  UHL  SEARCH  A  CODE  7  OR  A  CODE  12  DR  FOR  OUNED  DR'S  OF 

C  CODE  12  < ADSM'S)  THAT  HAVE  A  PARTICULAR  ACC.  IT  UILL  FIND 
C  THE  LARGEST  SECUENCE  tfUNBER  OF  THrtT  TYPE  USED  SO  FAR. 

C  —  INPUT  PAKA.".t i  ERS: 

C  NECA-NECC1 ACC)-THr  NUMBER  EQUIVALENT  CHARACTER  CODE  OF  THE 
C  TARGET  ACC. 

C-- INPUT/OUTPUT  PARAMETERS! 

C  IDRAA( 4 )-THE  DRAA  OF  THE  DR  TO  SEARCH.  ON  RETURN  IT  UILL  BE 
C  POSITIONED  TO  THE  OUNED  DR  WITH  THE  LARGEST 

C  (OR  UNCHANGED  IF  NSEQ=0> 

C — OUTPUT  PARAMETERS! 

C  NSEQ-LARGEST  SEQUENCE  NUMBER  USED  SO  FAR (ZERO  IF  NONE) 


SUBROUTINE  REMV1 I ( IOPT , IERR) 

C—MODULE:  MOPADS/UI 
C — REFERENCE!  MOPADS  VOL.  5.12 
C — PURPOSE: 

C  REMV1I  UILL  PERFORM  THE  “REMOVE"  COMMAND  IN  THE  "CREATE/EDIT 

C  SIMULATION  DATA  SET"  SUBPROCESS 

C 

C—INPUT  PARAMETERS: 

C  IOPT— OPTI ON 

C  O-PERFORH  COMMAND 

C  1 -PERFORM  HELP  COMMAND 

C  —  OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  .NE.O-DBCS  ERROR 


SUBROUTINE  RFAD1 1 ( IOPT , IERR ) 

C—MODULE:  MOPADS/UI 
C  — REFERENCE:  MOPADS  VOL.  5.12  • 

C—PURPOSE: 

C  RFAtll  UILL  LOCATE  THE  “ ( MAS f ER-DJRECTORY ) "  AND  PUT  ITS 
C  IDRAA  IN  HA1N1I. 

C  IT  UILL  ALSO  OPTIONALLY  MAKE  THE  “(MASTER-DIRECTORY)" 

C  CURRENT. 
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C — INPUT  PARAMETERS: 

C  IOPT-OPTION 

C  1  -DO  NOT  BAKE  THE  MASTER  DIRECTORY  DR  CURRENT 

C  2-DO  BAKE  THE  MASTER  DIRECTORY  DR  CURRENT 

C— OUTPUT  PARAMETERS: 

C  IERR-ERKOR  CODE 

C  O-NO  ERROR 

C  .6T.0-DB  ERROR  CODE 

C  .LT.O-CANNOT  LOCATE  "(MASTER-DIRECTORY)" 


% 


4 

4 


4 


I 
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k-0  21  -  SET  UP  SIMULATION  RUN  DATA 

The  programs  in  the  Set  Up  Simulation  Run  Daze,  subprocesses 
which  end  with  the  suffix  "21"  are  in  this  section. 


« 


i 


* 


t. 
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SUBROUTINE  UI2ICJOPT) 

C— MODULE:  ilOPADS/'JI 
C--REFERENCE:  MOPADS  VOL.  5.12 
C — PURPOSE: 

L  UI2I  IS  THE  ENTRY  POINT  TO  THE  "SET-UP  SIMULATION  RUN  DATA" 

C  SUBPROCESS 
C 

C— INPUT/OUTPUT  PARAMETERS: 

C  JO*1-  ON  INPUT  IT  IS  2.  IF  ON  OUTPUT  IT  IS  ZERO,  A  TERMINATE 
C  COMMAND  UILL  BE  EXECUTED. 


SUBROUTINE  ADD2I(TOPT,IERR) 

C — MODULE:  MOPADS/UI 
C— REFERENCE:  MOPADS  VOL.  5.12 
C — PURPOSE: 

C  ADD2I  UILL  PERFORM  THE  ADD  COMMAND  IN  THE  SET  UP  SIMULATION 

C  RUN  DATA  SUBPROCESS. 

C  —  INPUT  PARAMETERS: 

C  IOPT-OPTION 

C  O-DO  COMMAND 

C  1-HELP  COMMAND 

C— OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  .NE.O-DBCS  ERROR 


SUBROUTINE  CRIT2K IBRT,IERR,*) 

C — MODULE:  MOPADS/UI 
C—REFERENCE:  MOPADS  VOL.  5.12 
C— PURPOSE: 

C  CRIT2I  ALLOUS  EDITING  Or  THE  FIRE-UNIT  TO  CRITICAL-ASSET 
C  ASSIGNMENTS. 

C  —  INPUT/OUTPUT  PARAMETERS: 

C  IDRT(2)-DBAA  OF  THE  RUM-DATA  LL  OF  A  TAtTICAL  SCENARIO. 

C— OUTPUT  PARAMETERS: 

L  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  .NE.O-DBCS  ERROR  CODE 

C--ALTERNATE  RETURNS: 

C  1-IERR.NE.O 
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SUBROUTINE  DELE21 < IDPT, IERR) 

C --MODULE s  MOPADS/UI 
^ — REFERENCE:  HCPADS  VOL.  5. 12 
C — PURPOSE: 

C  DELE2I  UILL  PERFORM  THE  DELETE  COMMAND  IN  THE  SET  UP  SIMULATION 
C  RUN  DATA  SUBPROCESS. 

C — INPUT  PARAMETERS: 

C  I OPT— OPT  I OH 

C  0-D0  COMMAND 

C  1-HELP  COMMAND 

C— OUTPUT  PARAMETERS: 

C  1ERR-ERR0R  CODE 

C  0-N0  ERROR 

C  .NE.O-DSCS  ERROR 


SUBROUTINE  EDIT2I ( IOPT, IERR) 

C — MODULE:  MOPADS/UI 
C—REFERENCE:  MOPADS  VOL.  5.12 
C — PURPOSE: 

C  EDIT21  UILL  PERFORM  THE  EDIT  COMMAND  IN  THE  SET  UP  SIMULATION 

C  '  RUN  DATA  SUBPROCESS. 

C— INPUT  PARAMETERS: 

C  IOPT-OPTION 

C  O-DO  COMMAND 

C  1-KELP  COMMAND 

C— OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  0-N0  ERROR 

C  .NE.O-DBCS  ERROR 


C 

c 

c 

c 

c 

c 

c 

c 

c 

c 


SUBROUTINE  FTS2I(IPRT,IDNO, IBRAA.IERR,*,*) 

-MODULE:  MOPADS/UI 
-REFERENCE:  MOPADS  VOL.  5.12 
-PURPOSE: 

FTS2I  UILL  LOCATE  A  SPECIFIED  TACTICAL  SCENARIO  DR  IN  THE 
CURRENT  DR  ON  THE  WORKING  D3 . 

-INPUT  PARAMETERS: 

IPRT-PRINT  OPTION 

1- PRINT  ERROR  MESSAGE  IF  SCENARIO  NOT  PRESENT 

2- DO  NOT  PRINT 

IDNO-TACTICAL  SCENARIO  NUMBER 
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—OUTPUT  PARAMETER?: 

IDKAA1 D-DRA'  OF  THE  TACTICAL  SCENARIO.  ZERO  IF  NOT  FOUND. 
IERff-ERROR  LuGE 
O-MO  ERROR 

•NE.O-DBCS  ERROR  CODE 
—ALTERNATE  RETURNS; 
t  1-TACTICAL  SCENARIO  NOT  FOUND 

C  2-IERR.NE.O 


SUBROUTINE  USE2I(IOPTtlERR) 

C— MODULE:  MOPADS/UI 
C— REFERENCE:  MOPADS  VOL.  5.12 
C— PURPOSE: 

C  USE2I  UILL  PERFORM  THE  USE  COMMAND  IN  THE  SET  UP  SIMULATION 

C  RUN  DATA  SUBPROCESS 

C  —  INPUT  PARAMETERS: 

C  IOPT-DPT ION 

C  O-DO  COMMAND 

C  1-HELP  COMMAND 

C— OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  .NE.O-DBCS  ERROR  CODE 
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5-0  31  -  EXAMINE  STATISTICS 

The  programs  in  the  Examine  Statistics  subprocesses  vhich  end 
vith  the  suffix  ”31"  are  in  this  section. 
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SUBROUTINE  U13IU0PT) 

C--HODULE:  MQPAD3/UI 
C — REFERENCE:  MOPADS  VOL.  5.12 
C— PURPOSE: 

C  UI3I  IS  THE  ENTRY  POIL'T  TO  THE  'EXAMINE  STATISTICS" 

C  SUBPROCFSS 
C— INPUT/OUTPUT  PARAnETERS: 

C  JQPT-ON  IN°UT  IT  13  3.  IF  ON  OUTPUT  IT  IS  ZERO,  A  TERMINATE 
C  COMMAND  UILL  BE  EXECUTED 


SUBROUTINE  ADSM3KNR1  ,NR2,ITYP) 

C— MODULE:  MOPADS/UI 
C— REFERENCE:  MOPADS  VOL.  5.12 
C — PURPOSE: 

C  ADSM3I  UILL  QUERY  THE  USER  FOR  AN  ADS M  LABEL  OR  AN  ADSM  ACC. 

C  IT  UILL  RETURN  THE  TYPE  OF  THE  ADSM  AND  THE  COPY  ROU  NUMBER(S) 

C  OF  THAI  TYPE 
C— OUTPUT  PARAMETERS: 

C  NR1,NR2-CCPY  ROU  NUMBER(S)  OF  THE  SPECIFIED  ADSM. 

C  FOR  EXAMPLE:  IF  THE  USER  RESPONDS  UITH  "G1H2M, 

C  THEN  NR1 =NR2=THE  COPY  ROU  NUMBER  OF 

C  THAT  UNIT 

C  IF  THE  USER  RESPONDS  UITH  *H" , AN  ACC,  THEN 

C  NR1 =1  AND  NR2=NCNEXT- I .  I.E.  ALL  THE 

t  COPY  ROU  NUMBERS 

C  IF  NR  1 =0  ON  RETURN,  THEN  RETURN  TO  THE  SECONDARY  MENU 

C  IT  YP-THE  SYSTEM  MODULE  TYPE  OF  THE  SPECIFIED  ADSM.  E.G. 

C  FOR  AN  IHAUK ,  IT YP-4 


SUBROUTINE  CA1 031 ( IC2 , IERR, * ) 

C— HODULE:  MOPADS/UI 
C— REFERENCE:  MOPADS  VOL.  5.12 
C — PURPOSE: 

C  C A 1 031  IMPLEMENTS  THE  PRINT  COMMAND  FOR  THE  MAIN  CATEGORY 
C  OF  OPERATOR  TASK  FRACTION  STATISTICS 
C— INPUT  PARAMETERS: 

C  IC2-THE  SECONDARY  CATEGORY.  SEE  ISEC  IN  SUBROUTINE  MENU3I 

C  FOR  THE  VALUES. 


C — OUTPUT  PARAMETERS:  • 

C  IERR-EkXGR  CODE 

C  O-NO  ERROR 

C  .NE.O-DBCS  ERROR  CODE 

C — ALTERNATE  RETURNS: 

C  » -IERR.HE .0 


SUBROUTINE  CAT33I(IC2,IERR,*) 

C — MODULE:  MOPADS/UI 
C — REFERENCE:  MQPADS  VOL.  5.12 
C— PURPOSE: 

C  CAT33I  IMPLEMENTS  THE  PRINT  COMMAND  FOR  THE  MAIN  CATEGORY 
C  OF  AIR  DEFENSE  UNIT. 

Cr-INPUT  PARAMETERS: 

C  IC2-THE  SECONDARY  CATEGORY.  SEE  ISEC  IN  SUBROUTINE  NENU3I 

C  FOR  THE  VALUES. 

C — OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  . NE.O  DBCS  ERROR  CODE 

C — ALTERNATE  RETURNS: 

C  1—1  ERR .NE.O 


SUBROUTINE  CAT43I<IC2,IERRf*) 

C— MODULE:  MOPADS/UI 
C — REFERENCE:  MUPADS  VOL.  5.12 
C — PURPOSE : 

C  CAT43I  IMPLEMENTS  THE  PRINT  COMMAND  FOR  THE  MAIN  CATEGORY 
C  OF  OPERATOR 
c— INPUT  PARAMETERS: 

C  IC2-THE  SECONDARY  CATEGORY.  SEE  ISEC  IN  SUBROUTINE  MENU3I 

C  FOR  THE  VALUES. 

C — OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  .NE.O-DBCS  ERROR  CODE 

C— ALTERNATE  RETURNS: 

C  1 -IERR.NE.0 


SUBROUTINE  CAT53I < IC2 f 1ERP,* ) 

C— MODULE:  MOPADS/UI 

C — REFERENCE:  MOPADS  VOL.  5.12 

C—PURPOSE: 

C  CAT53I  IMPLEMENTS  THE  PRINT  COMMAND  FOR  THE  MAIN  CATEGORY 
C  OF  AIR  SCENARIO. 

C — INPUT  PARAMETERS: 

C  IC2-THE  SECONDARY  CATEGORY.  SEE  ISEC  IN  SUBROUTINE  HENU3I 
C  FOR  THE  VALUES. 

C — OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  .NE.O  DBCS  ERROR  CODE 

C--ALTERNATE  RETURNS: 

C  1-IERR.NE.O 


SUBROUTINE  CAT63I ( IC2, IERR, * )  *  f  I 

C— MODULE:  MOPADS/UI  ' 

C — REFERENCE:  MOPADS  VOL.  5.12 
C—PURPOSE: 

C  CAT 631  IMPLEMENTS  THE  PRINT  COMMAND  FOR  THE  MAIN  CATEGORY 

C  Oc  SAINT  TASK  NUDE  STATISTICS. 

C— INPUT  PARAMETERS: 

C  IC2-THE  SECONDARY  CATEGORY.  SEE  ISEC  IN  SUBROUTINE  MENU3I 

C  FOR  THE  VALUES. 

C  — OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  .NE.C  DBCS  ERROR  CODE 

C— ALTERNATE  RETURNS: 

C  1-IERR.NE.O 


SUBROUTINE  CAT73I (IC2, IERR, * )  j 

C-HODULE:  MOPADS/UI 
C— REFERENCE:  MOPADS  VOL.  5.12 
C  -PURPOSE: 

C  CAT73I  IMPLEMENTS  THE  PRINT  COMMAND  FOR  THE  MAIN  CATEGORY 
C  OF  SAINT  RESOURCE  STATISTICS. 

c- -input  parameters: 

C  IC2-THE  SECONDARY  CATEGORY.  SEE  ISEC  IN  SUBROUTINE  HENU3I 

C  FOR  THE  VALUES. 
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C— OUTP.IT  PARAMETERS: 
t  IERR--RR0R  CODE 

C  O-NQ  ERROR 

C  .NE.O  DBCS  ERROR  CODE 

C— ALTERNATE  RETURNS: 

C  1 -IERR.NE.0 


SUBROUTINE  CAT83I ( IC2 , IERR f * ) 

C— MODULE:  MOPADS/UI 
C— REFERENCE:  MOPADS  VOL.  5.12 
C — PURPOSE: 

C  CATB3I  IMPLEMENTS  THE  PRINT  COMMAND  FOR  THE  MAIN  CATEGORY 
C  OF  SAINT  USER  STATISTICS. 

C — INPUT  PARAMETERS: 

C  IC2-THE  SECONDARY  CATEGORY.  SEE  ISEC  IN  SUBROUTINE  MENU3I 

C  FOR  THE  VALUES. 

C — OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  . NE.O  DBCS  ERROR  CODE 

C— ALTERNATE  RETURNS: 

C  1 -IERR .NE .  0 


SUBROUTINE  CAT93HIC2, IERR,*) 

C--MODL"  F:  MP^ADS/UI 

L — REFERENCES  MOPADS  VOL.  5.12 

C--PURPOSE: 

C  CAT93I  IMPLEMENTS  THE  PRINT  COMMAND  FOR  THE  MAIN  CATEGORY 
C  OF  MOPADS  COUNT  STATISTICS. 

C--INPUT  PARAMETERS: 

C  IC2-THE  SECONDARY  CATEGORY.  SEE  ISEC  IN  SUBROUTINE  MENU3I 

C  FOR  THE  VALUES. 

C— OUTPUT  PARAMETERS: 

C  IEKR-ERROR  CODE 

C  O-NO  ERROR 

C  .NE.O  DBCS  ERROR  CODE 

C— ALTERNATE  RETURNS: 

C  1— IERR.NE.0 
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SUBROUTINE  DISP3I < IOPT . IERR ) 

—MODULE:  MOPADS/UI 
— REFERENCE:  HOPADS  VOL.  5.12 
—PURPOSE: 

DISP3I  UILL  PERFORM  THE  DISPLAY  COMMAND  IN  THE  "EXAMINE 
STATISTICS"  SUBPROCESS. 

—INPUT  PARAMETERS: 

IOPT  —OPT  I OH 

O-DO  COMMAND 
1-DO  HELP  COHHAND 
—OUTPUT  PARAMETERS: 

IERR-ERROR  CODE 
O-NO  ERROR 
C  .NE.O-DB  ERROR  CODE 


SUBROUTINE  FD0P3IUERR,*) 

C — MODULE:  MOPADS/UI 
C— REFERENCE:  HOPADS  VOL.  5.12 
C— PURPOSE: 

C  FDUP3I  UILL  FIND  THE  ACN'S  OF  ALL  ADSN'S  AND  LABELS  OF  ALL 
C  OPERATOR  TYPES  FOR  USE  IN  THE  "EXAMINE  STATISTICS" 

C  SUBPROCESS.  FD0P3I  ASSUMES  THAT  EACH  ADSM  TYPE  IN  THE 

C  SIMULATION  DATA  SET  IS  REPRESENTED  BY  A  REFERENCE  ADSM. 

C— OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  0-  NO  ERROR 

C  .NE.0-D3CS  ERROR  CODE 

C— ALTERNATE  RETURNS: 

C  1-IEKR.NE.O 


SUBROUTINE  HEAD3I (ISKIP) 

C —NODULE*  MOPADS/UI 
{—REFERENCE:  HOPPDR  VOL.  5.12 
C — PURPOSE: 

C  HEAD3I  UILL  PRINT  A  HEADING  CONSISTING  OF  THE 
C 

C  93  NANE 

C  96  TITLE 

C  SIMULATION  DATA  SET  NUMBER 

C  TACTICA’  SCENARIO  NUMBER 

C  RUN  NUMBER 

C 

C  IT  IS  PRINTED  ONLY  ON  THE  HOPADS  OUTPUT  FILE,  SO  IT  IF 

C  THE  DISPLAY  OPTION  <IST3I(4) >  IS  1,  HEAD3I  HAS  NO  EFFECT. 

C— INPUT  PARAMETERS: 

C  ISKIP-PAGE  SKIP  OPTION 
C  1-SKIP  PAGE  BEFORE  PRINTING 

C  2-90  NOT  SKIP  PAGE 

C  3-DO  PAGE  SKIP  QNLY(DO  NOT  PRINT  HEADER) 


SUBROUTINE  LNFD3KKLNS) 

C — NODULE:  NOPADS/UI 
C— REFERENCE:  NOPADS  VOL.  5.12 
C— PURPOSE: 

C  LNFD3I  UILL  LINE  FEED  ON  EACH  DISPLAY  DEVICE  SPECIFIED  BY  THE 
C  DISPLAY  OPTION,  IST3I<4),  IN  THE  "EXAMINE  STATISTICS" 

C  SUBPROCESS. 

C  — INPUT  PARAMETERS: 

C  KLNS-NUMBER  OF  LINES  TO  LINE  FEED (MAY  BE  ZERO) 


SUBROUTINE  NENU3I ( I  SCR , I SEL ) 

C— MODULE:  MOPADS/UI 
C— REFERENCE:  NOPADS  VOL.  5.12 
C— PURPOSE: 

C  MENU3I  MILL  PRINT  ONE  OF  THE  STATISTICS  MENU  SCREENS  AND 
C  RETURN  THE  USER'S  MENU  SELECTION. 
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INPUT  PARAMETERS! 

ISCR-SCREEN  NUMBER  TO  PRINT.  ISCR  IS  ONE  OF  THE  FOLLOWING! 
IF  ISCR’O,  RETURN  UITH  NO  ACTION 
IF  ISCR.LT.O,  THE  MENU  WILL  NOT  b'E  PRINTED,  ONLY  A 
RESPONSE  UILL  BE  REQUESTED. 


1- HAIN  CATEGORY  MENU 

2- 2N0ARY  CATEGORY  MENU  FOR  MAIN  CATEGORY  OF 


3- " 

4- " 

5- * 


6-* 

7- * 

8- " 

9-" 


10- 


A1R  DEFENSE 
UNIT 

OPERATORS 
AIR  SCENARIO 
SAINT  TASK 
NODE  STATS 
SAINT  RESOURCE 
STATS 

SAINT  USER  STATS 
NOPADS  COUNT 
STATS 

NOPADS  OPERATOR 
TASK  FRACTION 
STATS 

NOPADS  TRACE 


C— OUTPUT  PARAMETERS: 


C  ISEL-THE  USER'S  NENU  SELECTION,  ONLY  A  SUBSET  OF  THE 
C  FOLLOUINS  RESPONSES  IS  VALID  FOR  EACH  SCREEN  SHOWN  ABOVE. 

C  NENU  INSURES  THAT  A  RESPONSE  VALID  FOR  THE  CURRENT 

C  SCREEN  IS  61VEN.  IF  THE  USER  GIVES  THREE  INVALID 

C  RESPONSES  IN  A  SOU,  ISEL=t  IS  RETURNED. 

C 

C  1-EXIT  PRINT  COMMAND!-) 

C  2-RETURN  TO  MAIN  MENU!C) 

C  3-AIR  DEFENSE  UNIT < 1 ) 

C  4-0PERAT0RS12) 

C  5-AIR  SCENARIOS) 

C  4-SAINT  TASK  NODE  S fATISTICS! A) 

T  7-SAINT  RESOURCE  STATISTICS(B) 

C  8-SAINT  USER  S T A T I S I T I CS < C » 

C  9-MOPADS  COUNI  5T A T I S T I CS < D ) 

C  10-H0PADS  OPERATOR  TASK  FRACTION  STATISITICS 

C  1 1-HQPADS  TRACE 

C  12-TOGGLE  DISPLAY  DEVICE!*) 

C  13-ALL  STATIST ICSLEXCEPT  TRACE) (♦) 

C  14-PRINT  MENU  AGAIN!?) 

C  15-TIHE  INTERVAL(Ti) 

C  16-PRINT  TRACE!PR) 

C 
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SUBROUTINE  0«ER3I ( ITYP) 

—MODULE:  M1PADS/UI 
—REFERENCE:  MQPADS  VOL.  3.12 
—PURPOSE: 

0PER3I  MILL  QUERY  THE  USER  FOR  AN  OPERATOR  LABEL. 
FOR  EXAMPLE,  "ASO"  FOR  THE  1KAUC  ASO. 

ALSO,  CAN  BE  USED  FOR  THE 

OPERATOR  LABEL  TO  SIGNIFY  ALL  OPERATORS.  E.G. 

FOR  ALL  OPERATORS. 

—OUTPUT  PARAMETERS: 

ITYP-OPERATOR  TYPE. 

IF  ITYP.GT.O,  IT  IS  THE  OPERATOR  TYPE 
IF  ITYP.EO.O,  RETURN  TO  HENU 
IF  ITYP.EQ.-1,  AN  WAS  ENTERED 


j 

JUBPOUTINE  PC0U3I<NR0U,ICLCT ,NRN) 

-MODULE:  NOPADS/UI 

-REFERENCE:  NOPADS  VOL.  5.12  I 

-PURPOSE:  i 

PC0U3I  WILL  PRINT  COUNTER  STATISTICS 
FOR  ONE  ADSM  , 

-INPUT  PARAMETERS: 

NROU-COPY  ROW  NUMBER  OF  THE  ADSH 

ICLCT-INDEX  NUMBER  OF  THE  STATISTIC  TO  PRINT.  IF  ICLCT=0 
PRINT  ALL  STATISTICS  FOR  THIS  UNIT.  IF  ICLCT.LT.O, 
DO  NOT  PRINT  HEADER. 

NRN-RUN  NUMBER  FOR  THESE  STATISTICS. 


SUBROUTINE  PRES3KNROU,ICLCT,NRN) 

-MODULE:  MOPADS/UI 
-REFERENCE:  NOPADS  VOL.  5.12 
-PURPOSE: 

1  PRES3I  U ILL  PRINT  RESOURCE  STATISTICS 
FOR  ONE  ADSM.  FRES3I  MILL  NOT  PRINT  RESOURCES  WHOSE 
LABEL  IS  BLANK. 

-INPUT  PARAMETERS: 

NROU-COPY  RQU  NUMBER  OF  THE  ADSM 

ICLCT-INDEX  NUMBER  OF  THE  RESOURCE  TO  PRINT.  IF  ICLCT=0, 
PRINT  ALL  RESOURCE  STATISTICS  FOR  THIS  UNIT.  IF 
ICLCT.LT.O,  DO  NOT  PRINT  HEADER. 

HRN-NUHBER  Of  RUNS  FOR  THFSE  STATISTICS. 


SUBROUTINE  FRJN3I < IOFT,IERR) 

C— rtODULE:  MQPADS/UI 
t — REFERENCE:  MOPADS  VOL.  5.12 
C — PURPOSE: 

C  PRIN3I  UILL  EXECUTE  THE  PRINT  COMMAND  IN  THE  ' EXAMINE 

C  STATISTICS"  SUBPROCESS. 

C — INPUT  PARAMETERS: 

C  IOPT-OPTION 

C  O-DO  COMMAND 

C  1-DO  HELP  COMMAND 

C— OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  .GT.O-DNCS  ERROR  CODE 


SUBROUTINE  PRLN3I (LINL > 

C — MODULE:  MOPADS/UI 
C— REFERENCE:  MOPADS  VOL.  5.12 
C— PURPOSE: 

C  PRLN3I  UILL  PRINT  A  LINE  OF  STATISTICS  INFORMATION  IN 
C  VARIABLE  LINE31.  IT  UILL  PRINT  IT  ON  ALL  OUTPUT  DEVICES 

C  SPECIFIED  BT  THE  DISPLAY  OPTION,  1ST3IH),  OF  THE  "EXAMINE 

C  STATISTICS"  SUBPROCESS.  COLUMN  1  OF  LINE3I  UILL  HOT  BE 
C  PRINTED  ON  THE  TERMINAL.  IT  UILL  BE  PRINTED  ON  THE  LINE 

C  PRINTER  DEVICE  FOR  CARRIAGE  CONTROL. 

C  —  INPUT  PARAMETERS: 

C  LINL-LINE  LENGTH 

C  1-72  COLUMNS  < ONLY  THE  1ST  72  CCUJMNS  OF  LINE3I  UILL  BE 

C  PRINTED) 

C  2-130  COLUMNS 


SUBROUTINE  PTFS3I ( NROU, 1CLCT .NRN, IPOP) 

C— MODULE:  MOPADS/UI 
C  — REFERENCE:  MOPADS  VOL.  SI  1 2 
C  —  PURPOSE : 

C  PTFS3I  UILL  PRINT  OPERATOR  TASK  STATISTICS 

C  FOR  ONE  ADSM  AN!  ONE  OR  MORE  OPERATORS. 
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C— INPUT  PARAMETERS: 

C  NROU-COPT  RQU  NUMBER  OF  THE  ADSN 

C  ICLCT-TASK  NUMBER  a?  THE  STATISTIC  TO  PRINT.  IF  ICLCT=0, 

C  PRINT  ALL  STATISTIC?  FOR  THIS  UNIT.  IF  ICLCT.LT.O, 

C  DO  NOT  PRINT  HEADER. 

C  NRH-RUN  NUMBER  FOR  ThESE  STATISTICS. 

C  IDOP-CPERATOR  ID.  IF  lDOf*0, PRINT  FOR  ALL  OPERATORS  IN  THE  ADSN. 


SUBROUTINE  PTHS3I(NrOW, 1CLCT,NRN) 

C— MODULE:  MOPADS/UI 
C~ REFERENCE:  MOPACS  VOL.  5.12 
C— PURPOSE: 

C  PTHS3I  UILL  PRINT  TASK'  HISTOGRAMS 

C  FOR  ONE  ADSM 

C— INPUT  PARAMETERS: 

C  NROU-COPT  ROU  NUMBER  OF  THE  ADSN 

C  ICLCT-INDEX  NUMBER  OF  THE  HISTOGRAM  TO  PRINT.  IF  ICLCT*0, 

C  PRINT  ALL  HISTOGRAMS  FOR  THIS  UNIT. 

C  NRN-RUN  NUMBER  FOR  THESE  HISTOGRAMS. 


SUBROUTINE  PTSR31 (NROU,NODEf NRN) 

C--MODULE:  MOPADS/UI 
C~ REFERENCE:  MOPADS  VCL.  5.12 
C — PURPOSE: 

C  PTSR3I  UILL  PRINT  TASK  RUN  STATISTICS 
C  FOR  ONE  ADSM 

C—  INPUT  PARAMETERS: 

C  NROU-COPT  ROU  NUMBER  OF  THE  ADSM 

C  NODE-NODE  NUMBER  OF  THE  STATISTICS  TASK  TO  PRINT.  IF  NODE*©, 

C  PRINT  ALL  NODE  STATISTICS  FOR  THIS  UNIT.  IF  HODE.LT.O, 

C  DO  NOT  PRINT  HEADER. 

C  NRN-RUN  NUMBER  FOR  THESE  STATISTICS. 
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SUBROUTINE  PTSS3I (NROU,NGD£,NRN> 

C--MODULE:  MOPADS/UI 
C— REFERENCE:  MOPADS  VOL.  5.12 
C— PURPOSE: 

C  PTSS3I  WILL  PRINT  TASK  SUMMARY  STATISTICS 
C  FOR  ONE  ADSM 

C — INPUT  PARAMETERS: 

C  NROU-COPY  ROU  NUMBER  OF  THE  ADSM 

C  NODE-NODE  NUMBER  OF  THE  STATISTICS  TASK  TG  PRINT.  IF  NQDE=0, 
C  PRINT  ALL  NODE  STATISTICS  FOR  THIS  UNIT.  IF  NQDE.LT.O, 

C  DO  NOT  PRINT  HEADER. 

C  NRN-NUMBER  OF  RUNS  FOR  THESE  STATISTICS. 


SUBROUTINE  PUCL3I < NROU , ICLCT , HRN ) 

C — MODULE:  MOPADS/UI 
C — REFERENCE:  MOPADS  VOL.  5.12 
C— PURPOSE: 

C  PUCL3I  WILL  PRINT  USER  COLLECTED  OBSERVATION  STATISTICS 
C  FUR  ONE  ADSM 

C — INPUT  PARAMETERS: 

C  NROU-COPY  ROU  NUMBER  OF  THE  ADS!; 

C  ICLCT— INDEX  NUMBER  OF  THE  STATISTIC  TO  PRINT.  IF  ICLCT=0, 

C  PRINT  ALL  STATISTICS  FOR  THIS  UNIT.  IF  ICLCT.LT.O, 

C  DO  NOT  PRINT  HEADER. 

C  NRN-Rl'N  NUMBER  FOR  THESE  STATISTICS. 


SUBROUTINE  PUHS3I (NRQU, ICLCT ,NRN) 

C— MODULE:  MOPADS/UI 
C— REFERENCE:  MOPADS  VOL.  5.12 
C — PURPOSE: 

C  PUHS3I  UILL  PRINT  USER  HISTOGRAMS 

C  FOR  ONE  ADSM 

C— INPUT  PARAMETERS: 

C  NROU-COPY  ROU  NUMBER  OF  THE  ADSM 

C  IL'LCT-IMDEX  NUMBER  OF  THE  HISTOGRAM  TO  PRINT.  IF  ICLCT=0, 

C  PRINT  ALL  HISTOGRAMS  FOR  THIS  UNIT. 

C  NRN-RUN  NUMBER  FOR  THESE  HISTOGRAMS. 
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SUBROUTINE  PUTH3 I < HROU , ICLCT , KRN > 

C--MQDULE:  MOPADS/UI 
C--REFERENCE:  MOPADS  VOL.  3.12 
C--PURP0SE: 

C  PU7M3I  U ILL  PRINT  USER  COLLECTED  TIME  PERSISTENT  STATISTICS 
C  FOR  ONE  ADSH 

C — INPUT  PARAMETERS: 

C  NROU-COPT  ROU  NUMBER  OF  THE  AD3M 

C  ICLCT-INDEX  NUMBER  OF  THE  STATISTIC  TO  PRINT.  IF  ICLCT=0, 

C  PRINT  ALL  STATISTICS  FOR  THIS  UNIT.  IF  ICLCT.LT.O, 

C  DO  NOT  PRINT  HEADER. 

C  NRN-RUN  NUMBER  FOR  THESE  STATISTICS. 


SUBROUTINE  RCDB3IIN1 ,N2,N3,IDL,IELL,LRAY,IERR,*) 

C — MODULE:  MOPADS/UI 
C — REFERENCE:  MOPADS  VOL.  5.12 
C — PURPOSE: 

C  RCDB3I  UILL  READ  ANT  HOLLERITH  ARRAY  UITH  UP  TO  THREE 
C  DIMENSIONS  FROM  A  MOPADS  DATA  BASE,  CHARACTER,  ONE  DIMENSIONAL 
DATA  l 1ST.  IT  IS  USED  TO  READ  MSAINT  ARRAYS  FROM  THE 
DB  FOR  STATISTICS  ANALYSIS.  THE  ARRAY  MUST  BE 
URITTEN  TO  THE  DATA  BASE  UITH  SUBROUTINE 
UCDB3I . 

- NOTE -  HOLLERITH  IS  NOT  A  STANDARD  FORTRAN  77  DATA 

TYPE.  THIS  PROGRAM  IS  INCUDED  FOR  COMPATIBILITY 
UITH  MSAINT  UHICH  USES  HOLLERITH  FOR  LABELS. 

--INPUT  PARAMETERS: 

C  N1.N2,N3-DIMENSI0NS  OF  LRAT.  SEE  BELOU. 

C — INPUT/OUTPUT  PARAMETERS: 

C  IDL(2)-DBAA  OF  THE  DATA  LIST  TO  READ  FROM 

C  IELL-ON  INPUT,  THE  ELEMENT  OF  THE  DATA  LIST  UHICH 

C  CONTAINS  THE  FIRST  ELEMENT  OF  LRAY.  ON  RETURN, 

C  THE  ELEMENT  OF  THE  DATA  LIST  FGLLDUING  THE  LAST 

C  ELEMENT  OF  LRAY. 
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C — OUTPUT  PARAMETERS: 

C  LRAY(N1,N2,N3>-THE  HOLLERITH  ARRAY  TO  READ.  IF  THE  ARRAY 

C  HAS  FEWER  THAN  3  DIMENSIONS,  SEND 

C  N2  AND/OR  N3  EQUAL  TO  ZERO, 

t  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  .NE.O-DBCS  ERROR  CODE 

C— ALTERNATE  RETURNS: 

C  1 -IERR.NE.0 


SUBROUTINE  RIDB3KN1 ,N2,N3,IDL,IELL,IRAY,IERR,*> 

C-- MODULE:  HOPADS/UI 
C- -REFERENCE:  MOPADS  VOL.  5.12 
C — PURPOSE: 

C  RIDB3I  WILL  READ  ANY  INTEGER  ARRAY  WITH  UP  TO  THREE 
C  DIMENSIONS  FROM  A  MOPADS  DATA  BASE,  REAL,  ONE  DIMENSIONAL 

C  DATA  LIST.  IT  IS  USED  TO  READ  MSAINT  ARRAYS  FROM  THE 

C  DB  FOR  STATISTICS  ANALYSIS.  THE  ARRAY  MUST  BE 
C  WRITTEN  TO  THE  DATA  BASE  UITH  SUBROUTINE 

C  UIDB3I . 

C— INPUT  PARAMETERS: 

C  N1,N2,N3 -DIMENSIONS  OF  IRAY.  SEE  BELOU. 

C — INPUT/OUTPUT  PARAMETERS: 

C  IDL(2)-DBAA  OF  THE  DATA  LIST  TO  READ  FROM 

C  IELL-ON  INPUT,  THE  ELEMENT  OF  THE  DATA  LIST  WHICH 

C  CONTAINS  THE  FIRST  ELEMENT  OF  IRAY.  ON  RETURN, 

C  THE  ELEMENT  OF  THE  DATA  LIST  FOLLOWING  THE  LAST 

C  ELEMENT  Of  IRAY. 

C--OUTPUT  PARAMETERS: 

C  IRAYINI ,N2,N3>-TH£  INTEGER  ARRAY  TO  READ.  IF  THE  ARRAY 

C  HAS  FEWER  THAN  3  DIMENSIONS,  SEND 

C  N2  AND/OR  N3  EQUAL  TO  ZERO. 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  .NE.O-DBCS  ERROR  CODE 

C — ALTERNATE  RETURNS: 

C  1-IERR.NE.O 
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SUBROUTINE  RRPB3KN1 ,N2,N3.IDL,IELL,XRAY, IERR,*) 

C — MODULES  HOPADS/UI 
C — REFERENCE:  MOPADS  VOL.  5.12 
C— -PURPOSE: 

C  RRDB3I  UILL  READ  ANY  REAL  ARRAY  UI FH  UP  70  THREE 
C.  DIMENSIONS  FROM  A  MOPADS  DATA  BASE,  REAL,  ONE  D1HENSI0NAL 

C  DATA  LIST.  IT  IS  USED  TO  READ  MSA1NT  ARRAYS  FROM  THE 

C  D3  FOR  STATISTICS  ANALYSIS.  THE  ARRAY  HIJST  BE 
C  URITTEN  TO  THE  DATA  BASE  WITH  SUBROUTINE 

C  URDB31 

C — INPUT  PARAMETERS; 

C  Nt ,N2,NJ-DIHENSI0NS  OF  XRAY.  SEE  BELOU. 

C — INPUT/OUTPUT  PARAMETERS: 

C  I DL < 2 ) -DBA A  OF  THE  DATA  LIST  TO  URITE  TO. 

C  IELL-ON  INPUT,  THE  ELEMENT  OF  THE  DATA  LIST  TO 

C  READ  INTO  THE  FIRST  ELEMENT  OF  XRAY.  ON  RETURN, 

C  THE  ELEMENT  OF  THE  DATA  LIST  FOI.LOUING  T'iE  LAST 

C  ELEMENT  OF  XRAY. 

C  XRAYIN1 ,N2,N3)-THE  REAL  ARRAY  TO  READ.  IF  THE  ARRAY 

C  HAS  FEUER  THAN  3  DIMENSIONS,  SEND 

C  N2  AND/OR  N3  EQUAL  TO  ZERO. 

C — OUTPUT  PARAMETERS! 

C  IERR-ERROR  CODE 
C  O-NO  ERROR 

C  .NE.0-D8CS  ERROR  CODE 

C— ALTERNATE  RETURNS: 

C  1-IERR.NE.O 


SUBROUTINE  RSRN3I < NRN, IDRUN, IDSTAT , IERR,* ) 

— MODULE:  MOPADS/UI 
--REFERENCE:  MOPADS  VOL.  5.12 
—PURPOSE! 

RSRN3I  UILL  READ  THE  RUN  DATA  STATISI7ICS  INTO  SAINT  ARRAYS 
— INFUT  PARAMETERS: 

NRN-RUN  NUMBER 
—INPUT/OUTPUT  PARAMETERS! 

IDRUNH )-DRAA  OF  THE  RUN-NRN  DR 

IDSTATm-DRAA  OF  THE  STATISTICS  DR 
—OUTPUT  PARAMETERS: 

IERR-ERROR  CODE 

O-NO  DATA  BASE  ERROR 
.NE.0-D3CS  ERROR  CODE 
C — ALTERNATE  RETURNS: 

C  1-IERR.NE.O  OR  CORRECT  DB  DATA  NOT  FOUND 
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SUBROUTINE  RSTS3IUTS,IDBTS,IERR,*> 

C— MODULE:  J M0PAD3/UI 
C— REFERENCE:  HO.'ADE  VOL.  5.12 
C — PURPOSE : 

C  RSTS3I  MILL  READ  THE  HSAINT-DATA  AND  LABELS  DL'S  FROM 
C  A  CCDE  5  DIRECTORY  INTO  MSA I NT  ARRAYS 


C — INPUT  PARAMETERS! 

C  I TS- T AC T 1 CAL  SCENARIO  NUHBER 
C— INPUT/OUTPUT  PARAMETERS: 

C  IDBTSm-DRAA  OF  THE  STATISTICSTCUDE  5)  DR 

C— OUTPUT  PARAMETERS: 
c  ierMrror  CODE 

C  ;  O-NO  ERROR 

C  i  .NE.O-DBCS  ERROR  CODE 

C — ALTERNATE  RETURNS: 

C  1 -IERR.NE.0  OR  CORRECT  DATA  BASE  DATA  NOT  FOUND 


SUBROUTINE  SHOU3I(IOPT,IERR) 

C — MODULE:  HOPOBS/UI 
C— REFERENCE:  MOPADS  VOL.  5.12 
C — PURPOSE: 

C  SH0U3I  UILL  PERFORM  THE  SrfOU  COMMAND  IN  THE  "EXAMINE 

C  STATISTICS"  SUBPROCESS 

C  —  INPUT  PARAMETERS: 

C  IOPT— OPTION 

C  O-DO  THE  COMMAND 

C  1-DO  HELP  COMMAND 

C— OUTPUT  PARAMETERS: 

C  IERfi-ERRQR  CODE 

C  O-NO  ERROR 

C  .NE.O-DB  ERROR  CODE 


SUBROUTINE  T0GL3I 
C— REFERENCE:  MOPADS  VOL.  5.12 
C— PURPOSE: 

C  T06L3I  UILL  QUERY  THE  USER  FOR  THE  DISPLAY  DEVICF. 

C  ACCEPTABLE  RESPONSES  ARE  T - TERM  INAL  r  P-PRINTER,  AND 

C  B-BOTH.  If  THREE  ERRORS  ARE  MADE  IN  SUCCESSION, 

C  THE  DISPLAY  OPTION  IS  SET  TO  T. 
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SUBROUTINE  USE3 1 { I  OPT , IERR ) 

— MODULE:  MOPADS/UI 
— REFERENCE:  MOPADS  VOL.  5.12 
—PURPOSES 

USE3I  UILL  PERFORM  THE  USE  COMMAND  IN  THL  ‘EXAMINE  STATISTICS" 
SUBPROCESS. 

-INPUT  PARAMETERS: 

TOPT— OPTION 

0-D0  COMMAND 
1-DO  HELP  COMMAND 
—OUTPUT  PARAMETERS: 

IERR-ERROR  CODE 
O-NO  ERROR 
.NE.O-DB  ERROR  CODE 


SUBROUTINE  UCDB3I (LRAY,N1 ,N2,N3, IDL, IELL, IERR,*) 

—MODULE:  MOPADS/'JI 
-REFERENCE:  MOPADS  VOL.  5.12 
— PURPOSE: 

UCDB3I  UILL  URITE  ANY  HOLLERITH  ARRAY  UITH  UP  TO  THREE 
DIMENSIONS  TO  A  MOPADS  DATA  BASE,  CHARACTER,  ONE  DIMENSIONAL 
DATA  LIST.  IT  IS  USED  TO  URITE  MSAINT  ARRAYS  TO  THE 
DB  FOR  STATISTICS  ANALYSIS.  THE  ARRAY  MUST  BE 
RETRIEVED  FROM  THE  DATA  BASE  UITH  SUBROUTINE 
RCDB3I. 


- NOTE -  HOLLERITH  IS  NOT  A  STANDARD  FORTRAN  77  DATA 

TYPE.  THIS  PROGRAM  IS  1NCUDED  FOR 
COMPATIBILITY  UITH  MSAINT,  UHICH  USES 
HOLLERITH  FOR  LABELS. 

INPUT  PARAMETERS: 

LRAY(N1,N2,N3)-THE  HOLLERITH  ARRAY  TO  URITE.  IF  THE  ARRAY 
HAS  FEUER  THAN  3  DIMENSIONS,  SEND 
N2  AND/OR  N3  EQUAL  TO  ZERO. 

INPUT/OUTPUT  PARAMETERS: 

I DL ( 2 ) -DBAA  OF  THE  DATA  LIST  TO  URITE  TO. 

IELL-QN  INPUT,  THE  ELEMENT  OF  THE  DATA  LIST  TO 
C  RECEIVE  THE  FIRST  ELEMENT  OF  LRAY.  ON  RETURN, 

C  THE  ELEMENT  OF  THE  DATA  LIST  FOLLOUING  THE  LAST 

C  ELEMENT  OF  LRAY. 


C — OUTPUT  PARAMETERS: 

C  IcRR-ERRQR  CODE 
C  O-NO  ERROR 

C  .NE.O-DBCS  ERROR  CODE 

C — ALTERNATE  RETURNS: 

C  1-IERR.NE.O 


SUBROUTINE  UIDB3I ( IRAYrN1 ,N2,H3, IDL, IELL,IERR,»> 

C — MODULE:  MOPADS/U1 
C-REFERENCE:  MOPADS  VOL.  5.12 
C—PURPOSE: 

C  UIDB31  WILL  URITE  ANY  INTEGER  ARRAY  UITH  UP  TO  THREE 

C  DIMENSIONS  TO  A  MOPADS  DATA  BASE,  REAL,  ONE  DIMENSIONAL 

C  DATA  LIST.  IT  IS  USED  TO  URITE  MSAINI  ARRAYS  TO  THE 

C  DB  FOR  STATISTICS  ANALYSIS.  THE  ARRAY  MUST  BE 
C  RETRIEVED  FROM  THE  DATA  BASE  UITH  SUBROUTINE 

C  RIDB3I. 

C — INPUT  PARAMETERS: 

C  I  RAY  t  N 1 ,N2,N3)-THE  INTEGER  ARRAY  To  URITE.  IF  THE  ARRAY 
C  HAS  FFUER  THAN  3  DIMENSIONS,  SEND 

C  N2  AND/OR  N3  EQUAL  TO  ZERO. 

C — INPUT/OUTPUT  PARAMETERS: 

C  IDL(2>-DBAA  OF  THE  DATA  LIST  TO  URITE  III. 

C  IELL-ON  INPUT,  THE  ELEMENT  OF  THE  DATA  LIST  TO 

C  RECEIVE  THE  FIRST  ELEMENT  OF  IRAY.  ON  RETURN, 

C  THE  ELEMENT  OF  THE  DATA  LIST  FQLLCUING  THE  LAST 

C  ELEMENT  OF  IRAY. 

C — OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  .NE.O-DBCS  ERROR  CODE 

C--ALTERNATE  RETURNS: 

C  1-IERR.NE.O 


SUBROUTINE  URDB3I i XRAY , N1 , N2 ,N3, IDL , JELL , IERR , t ) 

C  — MODULE:  MOPADS/UI 
C— REFERENCE:  MOPADS  VOL.  5.12 
C—PURPOSE: 

C  URDB3I  UILL  URITE  ANY  REAL  ARRAY  UITH  UP  TO  THREE 

C  DIMENSIONS  TO  A  MOPADS  DATA  BASE,  REAL,  ONE  DIMENSIONAL 

C  DATA  LIST.  IT  IS  USED  TO  URITE  MSAINT  ARRAYS  TO  THE 

C  DB  FOR  STATISTICS  ANALYSIS.  THE  ARRAY  MUST  BE 

C  RETRIEVED  FROM  THE  DATA  BASE  UITH  SUBROUTINE 

C  RRDB3I 
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6-0  Ul  -  CREATE/EDIT  AIR  SCENARIO 

The  progrcms  in  the  Create/Edit  Air  Scenario  suhprocesses 
vhich  end  with  the  suffix  "1*1”  are  in  this  section. 
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SUBROUTINE  UI4* C J0P7) 

C-- NODULE:  MOPADS/UI 
C— REFERENCE?  NOFADS  VOL.  5.12 
C— PURPOSE: 

C  U X 4 1  IS  THE  SINGLE  ENTRY  POINT  FOR  THE  "CREATE/EDIT  SCENARIO 

C  DATA*  SUBPRDCESS. 

C 

C— INPUT/OUTPUT  PARAMETERS: 

C  JOPT-ON  INPU7  IT  IS  4.  ON  OUTPUT  IT  IS  ZERO  IF  A  TERMINATE 
C  COMMAND  HAS  BEEN  ISSUED. 


SUBROUTINE  ADAR4I (IOPT.IERR) 

C— MODULE:  MOPADS/UI 
C--REFERENCE:  MCPADS  VOL.  5.12 
C— PURPOSE: 

C  ADAR4I  WILL  PERFORN  THE  ADD-AIR  COMMAND  IN  THE  "CREATE/EDIT 

C  SCENARIO  DATA"  SU6PR0CESS 

C 

C — INPUT  PARAMETERS: 

C  IOPT-OPTION 

C  O-DO  COMMAND 

C  1-DO  HELP  COMMAND 

C— OUTPUT  PARAMETERS: 

IERR-ERROR  CODE 
O-NO  ERROR 
•NE.O-DBCS  ERROR 


SUBROUTINE  ADAS4I (IOPT.IERR) 

-MODULE:  MOPADS/UI 
-REFERENCE:  MOPADS  VOL.  5.12 
-PURPOSE: 

A9AS4I  UILl  PERFORM  THE  ADD-ASSET  COMMAND  IN  THE  'CREATE/EDIT 
SCENARIO  DATA’  SUBPROCESS. 

-INPUT  PARAMETERS: 

IOPT-OPTION 

O-DO  COMMAND 
1-HELP  COMMAND 
-OUTPUT  PARAMETERS: 

IERR-ERROR  CODE 
0-  NO  ERROR 
.NE.O-DBCS  ERRUR  CODE 
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SUBROUTINE  IlELE4i;iOPT,lERR> 

C- -MODULE:  MOPADS 'UI 
C— REFERENCE:  r.OPAIS  VOL.  5.12 
C~ PURPOSE: 

C  DELE4I  WILL  PERFORM  THE  DELETE  COMMAND  IN  THE  “CREATE/EDIT 

f  SCENARIO  DATA"  SUBPROCESS. 

C — INPUT  PARAHETEPSi 
C  I  OPT— OPT  I ON 

C  O-DO  COMMAND 

C  1-HELP  COMMAND 

C— OUTPUT  PARAMETERS: 

C  IERR-ERRQR  CODE 

C  O-NO  ERROR 

C  .NE.O-DPCS  ERROR  CODE 


SUBROUTINE  FAR4I (NDB , LABEL. IDRAA, IERR,*,*) 

C — MODULE:  MOPADS/UI  * 

C— REFERENCE:  MOPADS  VOL.  5.12 
C -PURPOSE: 

C  FAR4I  UILL  LOCATE  A  PARTICULAR  AIR  SCENARIO  IN  THE  CURRENT 
C  CRITICAL  ASSET  CONFIGURATION  DIRECTORY  OR  RETURN  AN 

C  INDICATION  THAT  IS  IS  NOT  PRESENT. 

C — INPUT  PARAMETERS: 

C  NDB-DATA  BASE  (1-UORKING,  2-REFERENCE) 

C  LABEL-(CHARACTER)  LABEL  OF  THE  AIR  SCENARIO  TO  FIND 
C  — OUTPUT  PARAMETERS: 

C  IDRAA(4)-DRAA  OF  THE  FOUND  AIR  SCENARIO.  ZERO  IF  NOT  FOUND. 
C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  .NE.O-DBCS  ERROR 

C — ALTERNATE  RETURNS: 

C  1-AIR  SCENARIO  "LABEL"  NOT  FOUND 

C  jj  2-IEKR.NE.O 


| Subroutine  fasmkndb, id, idraa, ierr,*,*) 

C — MODULE:  MOPADS/UI 
C — REFERENCE:  MOPADS  VOL.  5.12 
C — PURPOSE: 

C  F AS 4 1  UILL  LOCATE  A  PARTICULAR  ASSET  CONFIG.  IN  THE 
C  SCENARIOS  DIRECTORY  OP  RETURN  AN 
C  INDICATION  THAT  IS  IS  NOT  PRESENT. 


lA  *%  V 


C — INPUT  PARAMETERS: 

C  NDB-DATA  BASE  (I-U0NK1NG,  2-REFERENCE) 

C  ID-SECOND  UOR.O  OF  TKE  ASSET  ID  TO  FIND 
C— OUTPUT  PARAMETERS; 

C  IDRAA<4)-DRAA  OF  THE  FOUND  ASSET  CONFIG.  ZERO  IF  NOT  FOUND. 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  .NE.O-DBCS  ERROR 

C— ALTERNATE  RETURNS: 

C  1-ASSET  CONFIG. "ID"  NOT  FOUND 

C  2-IERR.NE.O 


SUBROUTINE  FTR4ICNDB,ITYP>IDBAA,IERR,*f«) 

C— MODULE:  MOPADS/UI 
C — REFERENCE:  MOPADS  VOL.  5.12 
C— PURPOSE: 

C  FTR4I  UILL  CHECK  FOR  THE  PRESENCE  OF  A  PARTICULAR  TRACK  TYPE 

C  (HOSTILE, FRIENDLY, OR  OTHER)  DL  IN  THE  CURRENT  AIR  SCENARIO 

C  DIRECTORY. 

C — INPUT  PARAMETERS: 

C  NDB-DATA  BASE  (1-UORKING, 2-REFERENCE) 

C  ITYP-TYPE  OF  DL  TO  LOOK  FOR 

C  1 -HOSTILE 

C  2-FRIENDLY 

C  3-OTHER 

C— OUTPUT  PARAMETERS: 

C  IDBAA(2)-DBAA  OF  THE  FOUND  DL 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  .NE.O-DBCS  ERROR 

C— ALTERNATE  RETURNS: 

C  1-TRACK  DL  OF  TYPE  1TYP  NOT  FOUND 

C  2-IERR.NE.O 


SUBROUTINE  GET  (I IOPT  f  IERR) 

C— MODULE:  MOPADS/UI 

C— REFERENCE:  MOPADS  VOL.  3.12 

C--PURPOSE: 

C  GET4I  WILL  PERFORM  THE  GET  COMMAND  IN  THE 

C  AIR  SCENARIO"  SUBPROCESS. 

C— INPUT  PARAMETERS: 

C  IOPT-OPTIQN 

C  O-DO  COMMAND 

C  1-HELF  COMMAND 


"CREATE/EDIT 
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C— OUTPUT  PARAMETERS: 

C  IERR-FR^OR  CODE 
C  0-N0  ERROR 

C  .Nt.O-DBCS  ERROR 


SUBROUTINE  RENA4IUUPT, IERR) 

C — MODULE*  NOPAIlS/UI 
C— REFERENCE!  HOPADS  VOL.  5.12 
C— PURPOSE! 

C  RENA4I  UILL  PERFORN  THE  RENAME  COMMAND  IN  THE  “CREATE/EDIT 

C  AIR  SCENARIO-  SUBPROCESS 

C 

C— INPUT  PARAMETERS! 

C  IOPT-OPTION 

C  O-DO  COMMAND 

C  1-HELP  COMMAND 

C— OUTPUT  PARAMETERS: 

C  1ERR-ERROR  CODE 

C  O-NO  ERROR 

C  .NE.O-DBCS  ERROR 


SUBROUTINE  RFSC4I<NDB,10PT,IERR) 

C— MODULE:  HOPADS/UI 
C— REFERENCE!  MOPADS  VOL.  5.12 
C— PURPOSE: 

RFSC4I  UILL  LOCATE  THE  "SCENARIOS"  DIRECTOR!  AND  PUT  ITS 
IDRAA  IN  IDRF5I  FOR  THE  SPECIFIED  DB. 

IT  UILL  ALSO  OPTIONALLY  MAKE  THE  "SCENARIOS" 

DIRECTORT  CURRENT. 

-INPUT  PARAMETERS: 

NDB-DATA  BASEl 1-UORKING, 2-REFERENCE) 

IOPT-OPTION 

1- DO  NOT  MAKE  THE  SCENARIOS  DR  CURRENT 

2- DO  HAKE  THE  SCENARIOS  DR  CURRENT 
—OUTPUT  PARAMETERS: 

IERR-ERROR  CODE 
O-NO  ERROR 
•ST.O-BB  ERROR  CODE 

.LT.O-CANNOT  LOCATE  "SCENARIOS"  DIRECTORT 
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SUBROUTINE  SAVE4I ( I0PT , IERR ) 

C — MODULE:  MUPADS/UI 
—REFERENCE:  MOPABS  VOL.  5.12 
—PURPOSE: 

SAVE4I  WILL  PERFORM  THE  SAVE  COMMAND  IN  THE  "CREATE/EDIT 
AIR  SCENARIO”  SUBPROCESS. 

—  INPUT  PARAMETERS: 

IOPT-OPTIQN 

O-DO  COMMAND 
1-HELP  COMMAND 
—OUTPUT  PARAMETERS: 

IERR-ERROR  CODE 
O-NO  ERROR 
.NE.O-DBCS  ERROR 
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7-0  51  -  CREATE/EDIT  REFERENCE  SYSTEM  MODULE 

The  programs  in  the  Create/Edit  Reference  System  Module  suh- 
processes  which  end  with  the  suffix  "51"  are  in  this  section. 
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SUBROUTINE  UISKJOPT) 

C— -NODULE:  MOPADS/UI 
C--REFERENCE:  MOPADS  VOL.  5.12 
C--PURPOSE: 

C  UI5I  IS  THE  ENTRY  POINT  TO  THE  rCREATE/EDT.T  REFERENCE  SYSTEM 
C  MODULE"  SUBPROCESS 
C 

C— INPUT/OUTPUT  PARAMETERS: 

C  JOPT-  ON  INPUT  IT  IS  5.  IF  ON  OUTPUT  IT  IS  ZERO,  A  TERMINATE 
C  COMMAND  UILL  BE  EXECUTED. 


SUBROUTINE  ADD5I ( IOPT , IERR > 

C — NODULE:  NOPADS/UI 
C--REFERENCE:  NOPADS  VOL.  5.12 
C — PURPOSE: 

C  ADD5I  UILL  PERFORM  AN  'ADD'  COMMAND  IN  THE  "CREATE/EDIT  REFERENCE 

C  SYSTEM  MODULE"  SUBPROCESS 

C 

C — INPUT  PARAMETERS: 

C  IOPT— DPT ION 

C  l»-PERFORN  COMMAND 

C  1 -PERFORM  HELP  COMMAND 

C— OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  .NE.O-DBCS  ERROR 


SUBROUTINE  CHAN5I (IOf T, IERR) 

C—NODULE:  nOPADS/UI 

C— REFERENCE:  MOPADS  VOL.  5.12 

C—PURPOSE: 

C  CHAN5I  UILL  PERFORM  A  CHANGE  COMMAND  IN  THE  CREATE/EDIT 

C  REFERENCE  SYSTEM  MODULE  SUBPROCESS. 

C — INPUT  PARAMETERS: 

IOPT— OPTION 

O-PERFORN  COMMAND 
1 -®ERFORH  HELP  COMMAND 
— OUT  PUT  PARAMETERS: 

IERR-ERROR  CODE 
O-NO  ERROR 
.NE.O-DBCS  ERROR 
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SUBROUTINE  «THENS  1  ( IERR f * # * ) 

C--MODULE:  ft.  VDS/UI 
C— REFERENCE:  ftCPADS  VOL.  5.12 
C — PURPOSE: 

C  CHEN5I  DOES  EDITING  OF  THE  ENVIRONMENT  STATE  VECTOR  OF 

C  THE  CURRENT  ADSft.  ONLY  THE  U0RKIN6  DB  MAY  BE  EDITED. 

C— OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  .NE.O-DBCS  ERROR 

C--ALTERNATE  RETURNS: 

C  1 -COMMAND  CANCELLED 

C  2- 1ERR.NE.0 


SUBROUTINE  CH0P5I ( IERR , ♦ , * > 

C— MODULE:  MOPADS/UI 
C— REFERENCE:  MOPADS  VOL.  5.12 
C— PURPOSE: 

C  CH0P5I  ALLOUS  THE  USER  TO  EDIT  OPERATOR  STATE  VECTORS  FOR 
C  THE  CURRENT  ADSM.  ONLY  THE  UORKING  DB  MAY  BE  EDITED. 

C 

C— OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  .NE.O-DBCS  ERROR  CODE 

C— ALTERNATE  RETURNS: 

C  1-COMMAND  CANCELLED 

C  2-IERR.NE.O 


SUBROUTINE  CHR5KIERR,*,*) 

C— MODULE:  MOPADS/UI 
C— REFERENCE:  MOPADS  VOL.  5.12 
C— PURPOSE: 

CHR5I  ALLOUS  THE  USER  TO  EDIT  THE  RESOURCE  AND  RESOURCE  LABEL 
DL'S  FOR  THE  CURRENT  ADSM.  ONLY  THE  UORKING  DB  MAY  BE  EDITED. 
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C—  OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  .NE.O-DBCS  ERROR  CODE 

C— ALTERNATE  RETURNS: 

C  1-COMMAND  CANCELLED 

C  2-IERR.NE.O 
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SUBROUTINE  CHTDSI ( IERR,*, *) 

C — NODULE:  MOPADS/UI 
C — REFERENCE:  HOPADS  VOL.  5.12 
C — PURPOSE: 

C  CHTD5I  ALLOWS  THE  USER  TO  EDIT  THE  TASK  DATA  LIST  OF  A  CURRFNT 

C  ADSM.  ONLY  THE  U0RKIN3  DB  HAT  BE  EDITED. 


C — OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  . NE.O-DBCS  ERROR 

C — ALTERNAlw  RETURNS: 

C  1 -COMMAND  CANCELLED 

C  2-IERR  .NE.O 


SUBROUTINE  CRES5I<NACC,IDRAA,  ,ERR,*,*> 

C — MODULE:  MOPADS/'IJI  j,1 

C— REFERENCE:  MOPADS  VOL,  5.12 
C— PURPOSE: 

C  CRES5I  WILL  CREATE  THE  ENVIRONMENTAL  STATE  VECTOR ( EN )  DATA 
C  LIST  FOR  A  NEW  REFERENCE  ADSM.  DEFAULT  VALUES  ARE  USED. 

C— INPUT  PARAMETERS: 

C  NACC-THE  VALUE  QF  NECC(ACC).  ACC  IS  THE  ADSM  CHARACTER  CODE 
C— INPUT/OUTPUT  PARAMETERS: 

C  IDRAA(A)-DRAA  OF  THE  ADSM 

C— OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  O-NO  ERRGR 

C  .NE.O-DB  ERROR 

C— ALTERNATE  RETURNS:  * 

C  O-NO  ERROR 

C  1 -DB  ERROR,  IERR. NE.O 

C  2-CANCEL  COMMAND 


SUBROUTINE  CR0P5I < NACC, IDRAA, IERR,* , * ) 

C— MODULE:  MOPADS/UI 
C— REFERENCE:  MOPADS  VOL.  5.12 
C— PURPOSE: 

C  CR0P5I  CREATES  OPERATOR  STATE  VECTORS(OP)  AND  AN  OPERATOR  TYPE 

C  < OT )  DL  IN  A  NEU  ADSM.  DEFAULT  VALUES  ARE  LOADED  FOR  ALL 

C  VARIABLES. 


ewjrssra'  &rz3nrmr r? : 


C — INPUT  PARAMETERS: 

C  NACC-THE  VALUE  OF  NECC(ACC).  ACC  IS  THE  ADSM  CODE  CHARACTER. 
C — INPUT/OUTPUT  PARAMETERS: 

C  IDRAA(4)-DRAA  OF  THE  ADSrt 
C— OUTPUT  PARAMETERS: 

C  IERR-ERRQR  CODE 

C  O-NO  ERROR 

C  .NE.O-DB  ERROR 

C — ALTERNATE  RETURNS: 

C  O-NO  ERROR 

C  1-DB  ERROR, IERR.NE.0 

C  2-CANCEL  ISSUED 


SUBROUTINE  CRRS5I(NACC,IDRAA,IERR,*,*) 

C—HODULE:  HOPADS/UI 
C— REFERENCE:  MOPADS  VOL.  5.12 
C — PURPOSE: 

C  CRRS5I  CREATES  THE  RESOURCE(R)  DATA  LIST  AND  THE  RESOURCE  LABEL 
C  (RL)  DATA  LIST  ON  NEU  REFERENCE  ADSM'?. 

C — INPUT  PARAMETERS: 

C  NACC-THE  VALUE  OF  NECCfACC)..  ACC  IS  THE  ADSM  CHARACTER  CODE 
C — INPUT/OUTPUT  PARAMETERS: 

C  IDRAA(4)-THE  DRAA  OF  THE  ADSM 
C— OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  .NE.O-DBCS  ERROR  CODE 

C— ALTERNATE  RF TURNS: 

C  O-NO  ERROR 

C  1-DB  ERROR,  IERR.NE.0 

C  2-CANCEL  ISSUED 


SUBROUTINE  CRTD5I <NACC,IDRAA, IERR,*,*) 

C — MODULE :  MOPADS/UI 
C — REFERENCE:  MOPADS  VOL.  5.12 
C— PURPOSE: 

C  CRTD5I  CREATES  A  TASK  DATA(TD)  LIST  IN  A  NEU  REFERENCE  ADSM. 
C  — INPUT  PARAMETERS: 

C  NACC-THE  VALUE  OF  NECCfACC).  ACC  IS  THE  ADSM  CHARACTER  CODE 
C — INPUT/OUTPUT  PARAMETERS: 

C  IDRAA(4)-DRAA  OF  THE  ADSM 
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SUBROUTINE  GTGL5I ( IGL,NEXT, IDBAA, IERR, ♦,*> 

C— NODULE:  HuPADS/UI 
C — REFERENCE:  HOPADS  VOL.  5.12 
C— PURPOSE: 

C  GTGL5I  UILL  QUERY  FOR  GOAL  PARAMETERS  AND  LOAD  THEN  INTO  AN 

C  OPERhTOP  STATE  VECTOR 

C 

C— INPUT  PARAMETERS: 

C  IGL-THE  GOAL  NUMBER  TO  GET  PARAMETER  VALUES  FOR 

C  NEXT - 1  ST  ELEMENT  OF  THE  OSV  FOR  GOAL  IGL. 

C--INPUT/OUTPUT  PARAMETERS: 

C  IDBAA ( 2 > -DBAA  Or  THE  OSV 

C— OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  .NE.O-DBCS  ERROR 

C— ALTERNATE  RETURNS: 

C  O-NO  ERROR 

C  1-DB  ERROR,  IERR.NE.0 

C  2-CANCEL  TYPED 


SUBROUTINE  0PCL5I<I0Pf,IPNT,NUEL,NLF.N,X) 

C— MODULE:  MOPADS/UI 
C — REFERENCE:  HOPADS  VOL.  5.12 
C — PURPOSE: 

C  GPCL5I  UILL  OPEN  OR  CLOSE  SPACE  IN  AN  ARRAY.  FOR  EXAMPLE, 

C  TO  OPEN  NllEL  ELEMENTS  AT  LOCATION  IPNT,  0PCL5I  UILL  SHIFT 
C  (END  OFF!)  THE  CONTENTS  OF  THE  ARRAY  X  DO  UN  NDEL  ELEMENTS 

STARTING  AT  IPNT  AND  STORE  ZERO  IN  THE  ELEMENTS  IPNT  TO 
IPNT+NDEL-1.  SIMILARLY,  TO  CLOSE  NDEL  ELEMENTS  STARTING  AT 
IPNT,  0PCL5I  UILL  OVFRURITE  ELEMENTS  IPNT  TO  IPNT*NDEL-1 
UITH  THE  ELEMENTS  IF’NI +HDEL  TO  IPNT+NDEL+NDEL-1 .  ALSO  ALL 
SUBSEQUENT  UORDS  UILL  BE  SHIFTED  AND  THE  ARRAY  UILL  BE 
ZERO  FILLED  FROM  THE  END. 

C--INPUT  PARAMETERS: 

C  IOPT-OPT I  ON 

C  1-OPEN 

C  2-CLOSE 

C  IPNT-ELEMENT  CF  X  AT  UHICH  TO  START  THE  SHIFT 

C  NDEL-NUMBER  OF  ELEMENTS  TO  SHIFT 

C  NLEN-LF.NGIH  OF  X 

C— INPUT/OUTPUT  PARAMETERS: 

C  X ( NLEN /-ARRAY  TO  SHIFT 
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SUBROUTINE  R£AD5I<NVALS,VALS> 

C~ NODULE:  MOPADS/UI 

C — REFERENCE:  NOPADS  VOL.  5.12 

C--PURPOSE: 

C  READ5I  WILL  READ  A  LINE  OF  NVnLS  VALUES  T0  THE  ARRAY  VALS  , 

C  IF  A  IS  SPECIFIED  FOR  ANY  VALUE,  THE  CORRESPONDING 

C  ELEMENT  OF  VALS  UILL  NOT  BE  CHANGED. 

C 

[--Tfjpuf  PARAMETERS: 

C  NVALS-THE  NUMBER  OF  VALUES  TO  READ.  ALL  MUST  BE  ON  ONE  LINE. 

C  IF  FEUER  THAN  NVALS  FIELDS  ARE  ON  THE  LINE,  THE  REMAINING 

C  ELEMENTS  OF  VALS  UILL  BE  UNCHANGED.  IF  NVALS=»0, RETURN  UITH 

C  NO  ACTION 

C — OUTPUT  PARAMETERS: 

C  VALS (NVALS)-OUT PUT  ARRAY 


SUBROUTINE  RENA5I (IOPT, 1ERR) 

C--MOIULE:  MOPADS/UI 
C— REFERENCE:  MOPADS  VOL.  5.12 
C — PURPOSE: 

C  RENA5I  'JILL  PERFORM  THE  RENAME  COMMAND  IN  THE  "CREATE/EDIT 

C  REFERENCE  SYSTEM  MODULE1*  SUBPROCESS. 

C--1NPUT  PARAMETERS: 

C  IQPT-OPTION 

C  O-DO  COMMAND 

C  1-DO  HELP  COMMAND 

C— OUTPUT  PARAMETERS: 

C  IERR-ERROK  CODE 

C  O-NO  ERROR 

C  .NE.0-D8CS  ERROR  CODE 


SUBROUTINE  RFAD5I < NDB , IOPT , IERRJ 
C — MODULE:  MOPADS/UI 
C— REFERENCE:  MOPADS  VOL.  5.12 
C—PURPOSE: 

C  RFAD5I  UI'l  LOCATE  THE  "REFERENCE  ADSM"  DIRECTORY  AND  PUT  ITS 

C  IDRAA  IN  IT  F5I  FOR  THE  SPECIFIED  DB. 

C  IT  UILL  ALSO  OPTIONALLY  MAKE  THE  "REFERENCE-ADSM" 

C  DIRECTORY  CURRENT. 
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C— INPUT  PARAMETERS: 

C  NJB-DATA  BASEd-UOPKING, 2-REFERENCE) 

C  I  OP  T -OP  T I ON 

C  1-DO  NOT  MAKE  THE  REF  ADSM  DR  CURRENT 

C  2-DO  HAKE  THF  REF-ADSM  DR  CURRENT 

C — OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  .GT.O-DB  ERROR  CODE 

C  .LT.O-CANNQT  LOCATE  “REFERENCE-ADSM"  DIRECTORY 


SUBROUTINE  SAVE5III0PT, IERR) 

C--HODULE:  HOPADS/UI 
C— REFERENCE:  HOPADS  VOL.  5.12 
C — PURPOSE: 

C  SAVE5I  UILL  PERFORM  THE  SAVE  COMMAND  IN  THE  "CREATE/EDIT 

C  REFERENCE  SYSTEM  MODULE"  SUBPROCESS. 

C 

C — INPUT  PARAMETERS: 

C  I OP  T — OP  T I  OH 

C  O-DO  COMMAND 

C  1-DO  HELP  COMMAND 

C— OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  .NE.O-DBCS  ERROR  CODE 


SUBROUTINE  USE5I ( IOPT f IERR ) 

C — HODULE:  HOPADS/UI 
C— REFERENCE:  HOPADS  VOL.  5.12 
C— PURPOSE: 

C  USE5I  UILL  PERFORM  THE  USE  COMMAND  IN  THE  "CREATE/EDIT 

C  REFERENCE  SYSTEM  MODULE"  SUBPROCESS 

C 

C — INPUT  PARAMETERS: 

C  IOPT-OPTIQN 

C  O-DO  COMMAND 

C  1-DO  HELP  COMMAND 

C— OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  O-NO  ERRGH 

C  .NE.O-DBCS  ERROR  CODE  , 
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VI.  USER  INSTRUCTIONS 


I 

Each  of  the  five  subprocesses  has  a  single  entry  point  program 
named  UI?I  where  the  "?"  is  an  integer  from  one  to  five.  This  sub¬ 
program  contains  the  FFSP  data  structure  for  the  commands  of  that 
subprocess.  Each  command  is  processed  by  a  separate  subprogram. 

The  command  programs  are  called  from  the  entry  point  program. 

i 

Tt  is,  therefore,  easy  to  understand  and  trace  the  structure 
of  each  subprocess  by  starting  at  the  entry  point  program  for  the 
subprocess.  Various  utility  programs  are  included  in  each 
subprocess  whose  purpose,  and  uses  can  be  discussed  from  their 
context  and  internal  documentation. 


V, 

V. 
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VII. 


ERROR  PROCESSING 


1- 0  THE  USER  INTERFACE 

The  user  interface  is  an  interactive  processor.  It  never  ter¬ 
minates  execution  of  the  MOPADS  program.  Data  entry  errors  are 
trapped  hy  the  program.  An  explanatory  message  is  printed,  and  the 
user  is  given  the  opportunity  to  re-enter  the  data.  Alternatively, 
the  program  may  cancel  the  command  being  processed  and  return  to  the 
command  mode.  The  user  may  then  issue  the  command  again. 

Execution  will  he  terminated,  however,  if  a  fatal  data  base 
error  occurs.  Such  errors  should  not  occur,  of  course,  but  non- 
recoverable  errors  in  the  DBCS  will  cause  the  program  to  be  ter¬ 
minated.  Little  damage  to  the  data  base  should  result,  because 
the  DBCS  operates  in  the  "safe"  mode  for  the  user  interface,  see 
Polito  1983(b).  Any  such  error  should  be  diagnosed  by  a  MOPADS 
modeler,  however. 

2- 0  THE  MAIN  MODULE 

The  primary  function  of  the  main  module  is  to  read  MOPADS  data 
cards  and  direct  control  to  the  user  interface  or  to  the  MSAINT 
module.  Therefore,  the  main  module  operates  as  though  it  were  in  a 
batch  environment.  Any  errors  found  in  the  data  cards  or  in  per¬ 
forming  initial  program  set-up  will  cause  execution  to  terminate. 
Error  processing  uses  subroutine  ERRORA  from  the  DBAP.  Also,  some 
error  messages  are  written  with  simple  write  statements  from  the 
Main  module. 
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VIII.  COMMON  VARIABLE  DEFINITIONS 


1-0  THE  USER  INTERFACE 

COMMON  variables  for  the  user  interface  are  shown  in  the 
following  forms. 
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VARIABLE  DEFINITION  AND/OR  DEFINING  EQUATION  INITAl  COHHON  BLOCK 

VALUE  (USER  VARIABLES  ONLY) 


n»l| » 


2-0  THE  MAIN  MODULE 

COMMON  variables  for  the  main  nodule  are  shown  in  the 
following  forms. 


\m 

iv.’.'S 
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TERMINOLOGY 


i 

i 

1-0  STAND VRD  MOPADS  TERMINOLOGY. 


AIR  DEFENSE 

SYSTEM 

A  component  of  Air  Defense  which  includes 
equipment  and  operators  and  for  which  techni¬ 
cal  and  tactical  training  are  required. 

Examples  are  IHAWK  and  the  AN/TSQ-73. 

AIR  DEFENSE  SYSTEM 
MODULE 

i 

i 

Models  of  operator  actions  and  equipment 
characteristics  for  Air  Defense  Systems  in 
the  MOPADS  software.  These  models  are  pre¬ 
pared  with  the  SAINT  simulation  language. 

Air  Defense  System  Modules  include  the  SAINT 
model  and  all  data  needed  to  completely 
define  task  element  time,  task  sequencing 
requirements,  and  human  factors  influences. 

AIR  SCENARIO 

A  spatial  and  temporal  record  of  aerial 
activities  and  characteristics  of  an  air 
defense  battle.  The  Air  Scenario  includes 
aircraft  tracks,  safe  corridors,  ECM,  and 
other  aircraft  and  airspace  data.  See  also 
Tactical  Scenario. 

BR/NCHING 

A  term  used  in  the  SAINT  simulation  language 
to  mean  the  process  by  which  TASK  nodes  are 
aequenced.  At  the  completion  of  the  simulated 
activity  at  a  TASK  node,  the  Branching  from 
that  node  determines  which  TASK  nodes  will  be 
simulated  next. 

DATA  BASE  CONTROL 
SYSTEM 

That  part  of  the  MOPADS  software  which  performs 
all  direct  communication  with  the  MOPADS  Data 
Base.  All  information  transfer  to  and  from 
the  data  base  is  performed  by  invoking  th*  sub¬ 
programs  which  make  up  the  Data  Base  Control 
System. 

DATA  SOURCE 
SPECIALIST 

A  specialist  in  obtaining  and  interpreting 

Army  documentation  and  other  data  needed  to 
prepare  Air  Defense  System  Modules. 

ENVIRONMENTAL 

STATE  VARIABLE 

An  element  of  an  Environmental  State  Vector. 

ENVIRONMENTAL 

STATE  VECTOR 

Aa  array  of  values  representing  conditions  or 
characteristics  that  may  affect  more  than  one 
operator .  Elements  of  Environmental  State 
Vectors  may  change  dynamically  during  a  MOPADS 
simulation  to  represent  changes  in  the  environ¬ 
ment  conditions. 

MODERATOR  FUNCTION 

A  mathenatical/logical  relationship  which 
alters  the  nominal  time  to  perform  an  operator 
activity  (usually  a  Task  Element).  The  nominal 
time  is  changed  to  represent  the  operator's 
capability  to  perform  the  activity  based  on  the 
Operator's  State  Vector. 

MOPADS  DATA  BASE 

A  computerized  data  base  designed  specifically 
to  support  the  MOPADS  software.  The  MOPADS 

Data  Base  contains  Simulation  Data  Set(s).  It 
communicates  interactively  with  MOPADS  Users 
daring  pre-  and  post-run  data  specification  and 
dynamically  with  the  SAPTT  software  during 
simulation. 

KOPADS  MODELER 

An  analyst  who  will  develop  Air  Defense  System 
Modules  and  modify/develop  the  MOPADS  software 
system. 

MOPADS  USER 

An  analyst  who  vill  design  and  conduct  simu¬ 
lation  experiments  with  the  MOPADS  software. 

MSAINT(KQPADS/SAINT) 

The  variant  of  SAUTT  used  in  the  MOPADS  system. 
The  standard  version  of  SAIHT  has  been  modified 
for  MOPADS  to  permit  shareable  subnetworks  and 
more  sophisticated  interrupts.  The  terns  SA1I.T 
and  KSA1.7T  are  used  interchangeably  when  no 
confusion  will  result.  See  also,  SAIIST. 

OPERATOR  STATE 
VARIABLE 

One  element  of  an  Operator  State  Vector. 

An  array  of  values  representing  the  condition 
end  characteristics  of  aa  operator  of  an  Air 
Defense  System.  Many  values  of  the  Operator 
State  Vector  vill  change  dynamically  during 
the  course  of  a  MOPADS  simulation  to  represent 
changes  in  operator  condition. 


OPERATOR  STATE 
VECTOR 


TASK  NODE 


A  modeling  symbol  used  in  the  SAIET  simulation 
language.  A  TASK  node  represents  an  activity; 
depending  upon  the  modeling  circumstances,  a 
TASK  node  may  represent  an  individual  activity 
such  as  a  Task  Element,  or  it  any  represent  an 
aggregated  activity  such  as  an  entire  Operator 
Task. 
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TASK  SEQUENCING 
MODERATOR  FUNCTION 

A  mathematical/logical  relationship  vhich 
selects  the  nert  Operator  Task  vhich  an 
operator  will  perform.  The  selection  is  based 
upon  operator  goal  seeking  characteristics. 

2-0  OTH3.  TERMINOLOGY 

• 

cm 

Character  data  list. 

CONTROL  PART 

The  first  10  vords  of  each  record.  The 
control  part  contains  information  used 
internally  by  the  J2BCS. 

DATA  BASE 

The  collection  of  user  information  and 
control  information  that  is  processed  by  the 
DECS. 

DATA  BASE  FILE 

A  computer  file  stored  on  disk  that 
contains  the  data  base. 

DATA  LIST 

A  list  of  values  (character  or  numeric) 
that  is  user  specified  and  is  stored  in  a 
data  base. 

» 
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DATA  PART 

That  part  of  a  record  that  stores  user 
specified  data.  Records  are  composed  of 
a  control  part  and  a  data  part. 

06 

Data  Base. 

DBA 

Data  Base  Address.  The  record  number  of 
a  record  on  disk. 

DBAA 

Data  Ease  Access  Address.  The  DBAA  Is  a  tvo 
vord  address  for  data  lists . consisting  of 
a  DBA  and  a  BBCSA. 

DECS 

Data  Base  Control  System. 

DBCSA 

Data  Base  Control  System  Address.  An 
address  in-core  vbere  a  record  is  stored. 

DBF 

Data  Base  File. 

DIRECTORY 

A  collection  of  data  lists  and  other 
directories. 

DL 

Data  List. 

DR 

Directory. 

DRAA 

Directory  Access  Address.  The  DRAA  is  a 
four  vord  address  for  directories  consisting 
of  a  DBA,  DBCSA,  and  the  current  directory 
and  data  list  position*  of  the  directory. 

ID 

Identify.  DL's  and  DR's  have  identifiers 
that  are  lists  of  integers  and  are  stored 
in  their  owning  directory. 

1DL 


Integer  Data  List 


INITIAL  DATA  BASE 
ADDRESS 

The  DBA  of  the  first  record  of  a  data  list 
or  directory. 

INTERNAL  STORE 

Record  storage  used  temporarily  for  working 
storage  by  the  DBCS. 

IS 

Internal  Store. 

LDL 

Label  Data  List. 

RDL 

Real  Data  List. 

SAF 

Smoothed  Access  Frequency. 

TEMPORARY  STORE 

Record  storage  for  records  that  are 
immediately  available  to  be  "bumped"  out 
of  core  by  inccming  records. 

TS 

Temporary  Store. 

WORKING  STORE 

Record  storage  for  records  that  have  semi¬ 
permanent  in-core  residence  because  of  the 
value  of  thair  SAF's. 

WS 

Working  Store. 

i.  purposf: 


This  document  describes  the  date,  management  system  for  the 
software  which  implements  the  Models  of  Operator  Performance  in  Air 
Defense  Systems  (MOPADS)  programs.  The  MOPADS  boftware  must  main¬ 
tain  a  great  deal  of  information  about  a  variety  of  subjects: 

1.  Data  which  describes  the  Air  Scenario  to  be  simulated, 

2.  Data  which  describes  the  tactical  scenario  which 
includes  location  and  characteristics  of  air  defense 
units,  the  command  and  control  system,  and  the  co¬ 
ordinate  reference  system, 

3.  Data  which  describes  the  characteristics  of  the  opera¬ 
tors  of  air  defense  systems  and  the  environment  in 
which  they  function, 

U.  Data  which  describes  the  dynamic  relationships  of 
operator  tasks,  and 

5.  Data  which  represents  statistics  collected  during 
simulations. 

All  of  this  information  must  be  maintained  in  an  easily  accessed  and 
edited  form,  and  it  must  be  addressed  in  a  way  that  permits  multiple 
data  setE  to  co-exist  without  confusion. 

The  most  effective  way  to  accomplish  this  is  with  a  unified 
data  manegement  system  or  a  data  base.  This  document  describes  the 
Data  Base  Control  System  (DBCS)  module  of  the  MOPADS  software.  The 
DBCS  is  described  in  general  terms  as  a  data  management  system.  The 
structure  of  the  MOPADS  specific  data  base  used  by  the  MOPADS  soft¬ 
ware  is  described  in  detail  elsewhere  (Polito  (1983a)). 

The  DBCS  is  a  non-traditieual  data  base  manager.  However,  the 
organization  of  the  MOPADS  data  base  file  most  nearly  resembles  a 
hierarchical  data  base.  It  iB  i  on-t r adit ion al  in  the  sense  that 
rapid  access  of  datum  elements  is  needed  during  MOPADS  simulations. 
The  DBCS  utilizes  a  data  address  that  is  passed  into  and  out  of  the 
DBCS  wnich  permits  rapid  access  of  required  data.  The  address  pre¬ 
cludes  most  hierarchical  searches  in  the  data  base  file  to  locate 
data;  thus  it  eliminates  many  disk  accesses.  Furthermore,  the  DBCS 
dynamically  retains  the  most  frequently  accessed  data  (not  merely 
the  most  recently  accessed)  in  core,  so  disk  reads  are  minimized. 
These  features  make  the  DBCS  a  reasonably  fast  tool  for  storage  and 
retrieval  of  data. 
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The  DBCS  module  is  a  collection  of  FORTRAN  77  subprograms  vhicb 
m ay  he  called  by  user  programs  to  manipulate  a  DBCS  data  case  file. 

It  has  extensive  error  trapping  features,  and  several  protection  mcdes 
from  read-only  to  a  risky,  but  fast,  mode  that  exposes  the  data  base 
to  damage  if  an  error  occurs.  This  flexibility  permits  the  user  pro¬ 
grams  to  tailor  the  DBCS  performance  to  their  requirements . 
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II.  DATA  STRUCTURE  DESCRIPTIONS 


1-0  DECS  DATA  BASES. 

1-1 .  Directories  and  Data  Lists. 

Directories  and  data  lists  (DR's  and  DL's)  are  the 
two  organizational  structures  that  comprise  a  DBCS  data  base.  A 
data  list  is  exactly  what  its  name  implies;  it  is  an  ordered  list 
of  data.  DL's  are  physically  where  information  is  stored  in  the 
data  base.  Data  lists  may  be  designated  as  being  of  type  real, 
integer,  or  character.  Abbreviations  for  each  type  are  RBL  (real), 
IDL  (integer),  and  CDL  (character).  RDL's  and  IDL's  may  be  one 
or  two  dimensional.  CDL's  may  have  only  one  dimension. 

Every  data  list  may  have  a  label  which  gives  its  name, 
and  every  element  of  a  data  list  may  have  a  label.  DBCS  labels 
are  maintained  in  special  label  data  lists  (LDL's).  LDL's  are 
maintained  internally  by  the  DBCS,  and  labels  may  have  only  25 
characters.  As  an  example,  a  character  data  list  may  have  an 
element  (say  the  seventh)  whose  label  is  "NAME"  and  whose  value 
is  ''JOHN  DOE."  It  is  possible  to  access  "JOHN  DOE"  by  requesting 
"NAME,"  but  this  is  slow.  A  faster  method  is  to  remember  that 
name  is  the  seventh  element  and  request  it  directly.  The  DBCS 
has  facilities  for  addressing  data  both  ways. 

Furthermore,  each  user  created  directory  and  data  list 
has  an  identifier  (ID)  which  is  a  list  of  integer  numbers.  The 
length  of  the  list  is  application  dependent.  The  ID's  provide 
another  way  to  locate  and  organize  data  in  the  data  base. 

Directories  are  collections  of  data  lists  and  other 
directories.  Directories  are  said  to  "own"  DL's  and  other  direc¬ 
tories  which  belong  to  it.  Thus  a  hierarchy  of  directories  is 
formed  in  which  each  directory  (with  the  exception  of  certain  system 
directories  which  are  described  later)  is  owned  by  another  directory 
and  which  may  own  other  directories.  This  hierarchy  is  a  tree 
since  no  directory  is  ovned  by  more  than  one  directory.  (Note:  it 
is  technically  possible  to  create  directories  which  have  no  cwner- 
i.e.  disjoint  trees,  and  disjoint  cycles  of  directories,  but  this 
practice  is  not  recommended  since  it  may  be  difficult  to  "find" 
these  disjoint  structures  in  the  data  base.) 

Figure  II-l  is  a  schematic  of  a  DBCS  data  base.  The  nota¬ 
tion  shown  in  the  legend  is  used  throughout  to  designate  directories 
and  data  lists  in  data  base  schematics.  This  notation  points  out 
that  directories  may  have  labels,  also.  Every  DBCS  data  base  (DB) 
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is  created  with  a  master  directory  whose  label  is  "(MASTER-DIRECTORY) ." 
In  addition,  a  disjoint  directory  labeled  "(SYSTEM-DIRECTORY)"  is  also 
created.  The  system  directory  is  used  internally  by  tae  DBCS  and  is 
never  directly  accessed  by  application  programs. 

An  application  program  has  created  four  additional  DR's  in 
Figure  II-l.  DIRECTORY-1  and  DIRECTORY-3  are  owned  by  (MASTER-DIR¬ 
ECTORY)  .  DIRECTORY-1  owns  DIRECTORY-2  and  DIRECTORY-3  owns 
DIRECTORY-!*  and  two  data  lists  labeled  DATA-LIST-1  and  DATA-LIST-2. 
(NOTE:  Labels  may  contain  any  character  includinj  blanks;  by  con¬ 
vention  we  will  use  instead  of  blanks  to  separate  words,  however.) 

There  is  no  limit  to  how  many  DL's  and  DR's  a  directory  may 
own.  Moreover,  DL's  and  DR's  may  be  created  and  deleted  at  will,  and 
DL's  may  be  read,  written,  extended,  and  shortened  at  any  time. 


The  Structure  of  a  Director 


A  directory  may  be  considered  as  a  list  of  DL  and  DR  ID's 
as  shown  schematically  in  Figure  II-2.  Every  DL  or  DR  which  belongs 
to  a  directory  must  have  an  ID  of  the  same  length,  but  this  length 
may  differ  from  director;  to  directory.  In  other  words,  it  is  a 
characteristic  of  the  directory. 


The  element  T  identifies  the  types  of  sntitity  (DR,  IDL,  RDL, 
or  CDL)  for  the  column.  The  address  element  A,  is  used  internally 
by  the  DBCS  to  physically  locate  information  on  the  data  base  file. 

The  physical  column  in  the  directory  which  holds  an  entity's  ID  is 
its  "position."  DL  and  DR  columns  will  be  intermixed  in  the  directory. 


A  directory  may  have  two  ranking  codes  (one  for  DL’s  and  one 
for  DR's)  which  determine  the  order  that  DL  and  DR  columns  appear  in 
the  directory.  Table  II-l  shows  how  to  assign  ranking  codes.  For 
example,  if  the  DL  ranking  code  is  2,  then  the  columns  which  represent 
DL's  in  the  directory  will  appear  in  order  of  increasing  values  of  ID 
element  2  (e.g.,  element  2  of  column  h  would  have  a  greater  value  than 
element  2  of  column  2).  Conversely,  if  the  ranking  code  were  -2,  the 
columns  would  appear  in  decreasing  order  of  ID  element  2.  No  ordering 
is  specified  if  the  ranking  code  is  zero.  In  case  of  ties,  the 
ordering  is  not  predictable. 


A  directory  that  is  being  accessed  has  a  current  "directory  posi¬ 
tion"  for  DL's  and  DR's  which  is  the  most  recently  accessed  directory 
and  data  list  position.  For  example,  if  column  6  were  the  most  recently 
accessed  data  list  and  column  22  were  the  most  recently  accessed  direc¬ 
tory,  then  the  current  data  list  position  and  the  current  directory 
position  would  be  6  and  22,  respectively. 


The  DBCS  automatically  positions  DL's  and  DR's  within  a  directory 
The  only  time  an  application  program  need  be  concerned  with  the  direc¬ 
tory  position  is  when  accessing  data  with  instructions  such  as:  "find 


-  identifiers  of  owned  DL's  and  DR's 

-  entity  type  (1-DR,  2-IDL,  3-RDL,  4-CDL) 

-  internal  address  to  the  owned  entity 

-  the  column  number  is  the  "position"  of 
the  entity 


Figure  II-2.  Directory  Structure. 


the  next  data  list  in  the  forward  (increasing  directory  position) 
direction,"  or  "find  the  next  directory  whose  ID  element  k  is  less 
than  6  in  the  backward  direction."  In  these  cases,  it  is  necessary 
for  the  application  urogram  to  r.acain  aware  of  the  current  directory 
position. 


Table  II-l.  Ranking  Codes  for  Directories  and  Data  Lists 


Ranking  Codes  for  Owned  Directories 


Meaning 


not  ranked 

increasing  order  of  ID  element  n 
decreasing  order  of  ID  element  n 


Ranking  Codes  for  Owned  Data  Lists 


Meaning 


not  ranked 


increasing  order  of  ID  element  n 
decreasing  order  of  ID  element  n 


The  Structure  of  a  Data  List. 


Data  lists  are  merely  one  or  two  dimensional  lists  of 
numbers  or  character  strings.  Character  data  lists  (CDL's)  may  only 
be  one  dimensional,  but  the  length  of  each  element  (in  characters)  is 
user  selectable.  In  other  words,  one  CDL  may  have  10  characters  per 
element  and  another  may  have  kO.  Label  data  lists  (LDL's)  are  special 
CDL's  which  are  manipulated  only  by  the  DBCS  and  they  always  have  25 
characters/label. 

Real  and  integer  data  lists  (RDL's  and  IDL's)  may  have  one  or 
two  dimensions.  Two  dimensional  DL's  may  be  thought  of  in  the  usual 
row-column  sense  except  in  one  important  instance.  The  DBCS  allows 
DL's  to  be  extended  (i.e.,  more  elements  added)  and  truncated  (elements 
deleted).  For  one  dimensional  DL's,  this  produces  no  conceptual 
difficulties;  elements  are  added  and  deleted  from  the  end  of  the  DL. 

For  two  dimensional  DL's,  we  must  specify  whether  columns  or 
rows  are  to  be  added  or  deleted.  This  gives  rise  to  two  types  of 
two  dimensional  daua  lists:  "column  oriented"  and  "row  oriented." 


If  a  DL  is  column  oriented,  then  the  maximum  row  dimension  is  speci¬ 
fied  and  columns  may  he  added  and  deleted  at  will.  If  it  is  row 
oriented,  then  the  maximum  column  dimension  is  specified  and  as  many 
rows  as  desired  may  be  added  or  deleted.  Figure  II-3  shows  this 
distinction. 

If  the  rov  and  column  dimensions  of  a  two-dimensional  DL  will 
remain  fixed,  then  the  orientation  should  be  chosen  to  maximize 
access  efficiency.  It  is  most  efficient  to  access  column  oriented 
DL's  by  columns  (or  parts  of  columns)  and  row  oriented  DL's  by  rows 
(or  parts  thereof).  For  example,  it  is  faster  to  read  all  of  rov  6 
of  a  row  oriented  DL  than  row  6  of  a  column  oriented  DL. 

2-0  DECS  DATA  BASE  FILES. 

2-1.  Structure  of  the  Data  Base  File. 

The  D3CS  data  files  are  direct  access,  unformatted  FORTRAN 
files.  They  are  comprised  of  United  lists  or  records.  This  means 
that  each  record  in  such  a  file  may  have  a  predecessor  and  a  suc¬ 
cessor  record.  The  record  numbers  of  the  predecessor  and  successor 
records  are  stored  in  data  fields  of  the  record  (if  no  predecessor  or 
successor  exists,  then  the  appropriate  field  is  zero).  A  record's 
Data  Base  Address  (DBA)  is  its  record  number  The  DBA  is  the  primary 
means  of  locating  ir formation  on  the  DB  file.  The  Initial  Data  Base 
address  of  a  DL  or  DR  is  the  DBA  of  the  first  record  that  makes  up  its 
record  chain. 

Data  lists  and  directories  are  linked  chains  of  records  that 
contain  sufficient  storage  to  hold  all  of  the  information  ir.  the  DL 
or  DR.  The  DBCS  performs  all  bookkeeping  and  record  manipulation; 
thus  the  details  of  the  data  file  implementation  are  transparent  to 
the  user. 

2-2.  Structure  of  Data  Records. 

Record  one  is  a  special  record  which  contains  various  DB 
parameters.  It  has  a  special  structure  which  is  described  sub¬ 
sequently.  All  other  records  have  the  structure  described  in  this 
section. 

Records  are  divided  into  two  sections:  the  control  part  end 
the  data  part.  The  control  part  contains  information  that  allows  the 
DBCS  to  efficiently  store  and  retrieve  information  from  the  DB.  The 
data  part  holds  information  inserted  by  the  user.  There  are  ten 
words  in  the  control  part  of  each  record  (actually,  there  is  a  DBCS 
variable,  IWCPD ,  that  determines  the  control  part  size,  but  this  is 
only  to  allow  for  possible  DBCS  modifications).  All  remaining  words 
in  a  record  belong  to  the  data  part.  The  total  record  size  is  under 
user  control  and  may  be  selected  to  maximize  the  efficiency  of  disk 
storage  hardware. 
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The  definitions  oi  the  various  fields  in  the  control  part  of 
records  is  shown  in  Table  II-2. 

Words  VI  and  V3  are  the  predecessor  and  successor  DBA's, 
respectively.  W2  is  the  record’s  own  DBA.  When  a  record  is  read 
into  core  storage,  W2  is  made  negative  if  any  of  the  data  in  the 
record  is  subsequently  changed.  This  is  an  indication  that  the 
in-cor*  version  of  the  record  has  information  that  is  not  yet  up¬ 
dated  cn  the  data  base  file.  Wl»  is  the  Initial  DBA  of  the  DL  or  DR. 
Thus,  it  is  always  possible  to  go  directly  to  the  beginning  of  a 
record  chain,  and,  more  importantly,  it  i3  possible  to  determine  if 
two  records  belong  to  the  same  record  chain  by  comparing  their  WU 
values. 


If  the  record  is  a  data  list,  then  it  has  an  LDL  (which  may 
be  empty  if  no  elements  are  labeled).  The  initial  DBA  of  the  LDL 
is  given  in  W5*  The  label  of  the  data  list  is  the  first  element  of 
its  LDL.  Then  the  second  element  of  LDL  is  the  label  of  the  first 
element  of  the  DL  and  so  on.  LDL's  have  W5=0  since  they  have  no 
LDL. 


If  the  record  belongs  to  a  directory,  W5  contains  DL  and  DR 
ranking  information.  The  ranking  codes,  RDL  and  RPR,  for  data  lists 
and  directories  have  values  as  shown  in  Table  II-l.  Directories 
are  actually  two  dimensional,  column  oriented  IDL's  whose  maximum 
row  dimension  is  the  length  of  the  ID's  plus  two  (see  Figure  II-2) 
IJWADD  (See  Section  VIII)  is  a  DECS  variable  whose  value  is  two  (the 
number  of  extra  rows  in  directories).  The  formula  W5  =  RDL*(W8-NW 
ADD)  +  RDR  is  an  easily  coded  and  decoded  way  to  store  the  ranking 
codes  in  a  single  word.  (See  SUBROUTINE  RKDIRD  in  Section  V  for 
details. ) 

W6  is  the  Initial  DBA  of  the  owner  of  the  record.  It  is  a 
directory  for  DR's,  IDL's,  RDL's,  and  CDL's  (zero  for  no  owner)  and 
the  owner  DL  for  LDL's.  W7  is  the  DB  entity  type. 

W3  holds  dimension  information  for  this  entity.  For  CDL's 
and  LDL's,  W8  is  the  number  of  characters  per  element.  '  These  DLrs 
hold  character  data,  and  the  length  in  characters  of  each  element 
must  be  specified.  W8  is  always  25  for  LDL's.  This  implies  that 
DL  element  labels  and  DL  labels  may  have  a  maximum  of  25  characters. 
CDL's  and  LDL's  are  one  dimensional  lists. 

RDL's  and  IDL's  may  be  two  dimensional  and  either  row  or 
column  oriented.  For  one  dimensional  IDL's  and  RDL's,  W8  =  1.  For 
two  dimensional  column  oriented  DL's,  W8  is  the  maximum  row  dimen¬ 
sion.  It  is  the  negative  of  the  maximum  column  dimension  for  row 
oriented  DL's.  For  directories,  W8  is  the  maximum  row  dimension 
since  DR's  are  Just  special  two  dimensional  IDL's. 
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Table  II-2.  The  Control  Part  of  Records 


Description 

Predecessor  DBA  (zero  if  none) 

DBA  of  this  record 

Successor  DBA  (zero  if  none) 

Initial  Date  Base  Address  of  the  DL  or  DR 

5  I  W5  I  For  Data  Lilts:  The  Initial  DBA  of  the  LDL 

I  I  (zero  if  this  is  an  LDL) 


For  Directories:  The  combined  ranking  codes 
for  DL's  or  DR's. 
RDL*(W8-NVADD)+RDR 
See  discussion 


6 

W6 

Initial  DBA  of  the  owner  directory  (zero  if 
none).  Exception:  if  this  is  an  LDL,  W6  is 
the  Initial  DBA  of  the  owning  DL. 

B 

V7 

Entity  Type  ( 1-Directory,  2-IDL,  3-RDL, 

U-CDL,  5 -LDL) 

8  W8  For  Data  Lists: 


a.  Fcr  CDL's  and  LDL's:  the  number  of 
characters  per  element 


b.  For  IDL's  and  RDL's:  the  maximum 
row  or  column  dimensions 


If  W8>1,  column  oriented 
If  W5<0,  row  ori  nted 
If  W8=l,  one  dimensional 
See  discussion 


For  Directories: 

The  maximum  row  dimensions  (directories 
are  really  column  oriented 
IDL's).  See  discussion. 

9  W9  Index  of  the  first  element  of  the  DL  or  DR 

in  this  record 

10  W10  Index  of  the  last  element  of  the  DL  or  DR 

in  this  record 
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W9  and  W10  are  the  indexes  uf  the  first  and  last  elements  in 
the  data  part  of  the  record.  Elements  arc  numbered  from  one  to  infin¬ 
ity  (even  for  tvo  dimensional  DL’s).  Thus,  the  first  lecord  of  a  DL 
might  have  elements  cne  tc  fifty  (W9»l,  V1O50),  and  the  second  record 
could  have  elements  51  to  58  (V9“51,  WIO=58).  A  new  record  is  added 
to  the  record  chain  vhen  the  data  part  of  the  current  record  is  filled. 
The  CBCS  internally  determines  vhich  elements  belong  to  what  row  and 
column  for  tvo  dimensional  DL's  and  DR's. 

Undefined  numeric  elements  are  zero  and  character  elements  are 
blank.  For  example,  if  element  50  of  an  ID!  is  set  to  zero,  but 
elements  I-U9  vere  not  yet  set,  then  elements  I-U9  exist  and  are  equal 
to  zero. 

When  a  data  list  is  created,  an  LLL  is  created  for  it  vhich 
always  contains  at  least  one  element  (the  DL  label).  If  no  label  is 
specified  for  the  DL,  a  default  t.f  "(UNLABELED) "  is  used.  If  the  data 
list  is  then  populated,  but  no  element  labels  are  specified,  then  the 
LDL  still  contains  only  or.e  element.  However,  if  the  label  of  an  un¬ 
labeled  DL  element  is  requested,  the  DBCS  responds  with  "(UNLABELED) ." 

In  addition  to  the  user  created  information,  the  data  parts  of 
each  record  contain  two  numbers  used  internally  by  the  DBCS.  The  DBCS 
retains  frequently  accessed  records  in  fast  core  storage  in  order  to 
reduce  the  number  of  disk  accesses.  In  order  to  do  this,  it  must  keep 
track  of  the  access  frequency  of  each  record.  It  needs  tvo  values  to 
do  this.  The  DBCS  counts  the  cumulative  number  «  *  accesses  to  the 
data  base  and  computes  a  smoothed  aucess  frequency  for  each  record. 
When  a  record  is  written  to  disk,  the  current  access  count  and  the 
current  smoothed  access  frequency  for  the  record  are  written  with  it. 
The  mnemonics  for  these  values  are  TSLU  and  SAP,  respectively.  These 
concepts  are  discussed  more  fully  in  Section  3-0  below. 

Figure  Il-b  shows  how  these  values  are  stored  in  the  lata  pare. 
There  are  two  cases.  For  directories  and  numeric  data  lists,  TSLU 
and  SAF  are  stored  in  the  first  two  words  of  the:  data  part.  The  sub¬ 
sequent  words  in  the  data  part  are  the  data  list  elements  indexed  by 
W9  and  V10  of  the  control  part.  For  character  data  lists  and  label 
data  lists,  TSLU  is  written  to  the  first  15  characters  of  the  data 
part  with  a  G15-7  FORTRAN  format  editing  specification.  SAF  is 
written  to  the  next  9  characters  with  an  F9.6  specification.  The 
remaining  characters  of  the  data  part  are  partitioned  into  elements 
of  lengti  W8  and  are  indexed  by  W9  and  W10.  Any  partial  elements  (of 
less  than  W8  characters)  at  the  end  of  the  data  part  are  unused.  In 
other  words,  character  elements  are  not  split  between  records. 
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1 ,  Data  Parts  for  Directories,  Integer  PC's  and  Real  PL's 


2. 


Figure 


12  3  4 


TSLU 

SAF 

elements  Indexed  by  W9  and 
tflO  of  the  control  part 


Data  Parts  for  Character  and  Label  Data  Lists 


h—  15  - —  9  - N 


TSLU 

SAF 

•  •  • 

J 

elements  indexed  by  W9  and 
W10  of  the  control  part 


TSLU  is  stored  with  a  G15.7  specification. 
SAF  is  stored  with  a  F9.6  specification. 


II-L.  Structure  of  the  Data  Parts  of  Records. 
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2-3.  The  Master  Directory 


Every  BB  has  a  master  directory  whose  DBA  is  record  two. 
It  has  the  following  characteristics: 


label 
DL's  and  DR’s 
words /ID 
V6 


"(MASTER  DIRECTORY ) " 

unranked 

user  specified 

zero 


The  DBA  of  the  master  directory  is  always  two.  Therefore  it  provides 
a  standard  entry  to  the  DB  file.  Every  DR  and  DL  in  the  DB  should 
have  an  ownership  chain  which  leads  ultimately  to  the  master  directory. 
The  user  may  insert  DL's  and  DR's  in  the  master  directory  Just  as  in 
any  other  directory. 

2-1* .  The  System  Directory. 

The  initial  DBA  of  the  system  directory  is  three.  The 
system  directory  owns  three  DL's  that  are  used  internally  by  the  DECS. 
The  user  need  never  be  directly  concerned  with  the  system  directory. 

The  system  directory  has  one  word  per  ID  and  the  ID's  of  the  three 
DL's  are  0,  1,  and  2.  The  DL's  are  as  follows: 


IP's 

0  -  The  Available  Record  List  (ARL). 

See  Section  2-6  below. 

1  -  The  directory  label  data  list. 

2  The  initial  DBA's  of  all 
directories. 

The  directory  label  DL  is  a  CDL  which  has  the  labels  of  all  directories 
in  the  DB.  It  has  1*0  characters  per  element,  so  directory  labels  may 
have  up  to  1*0  characters.  If  no  label  is  specified  when  a  directory  is 
created,  "(UNLABELED)"  is  used. 

The  initial  DBA  of  each  directory  is  stored  in  the  element  of  the 
DL  with  ID=2  that  corresponds  to  its  label  in  ID=1.  In  other  words,  the 
DR  whose  label  is  in  element  16  of  the  directory  label  data  list  will 
have  its  initial  DBA  in  element  16  of  the  ID=2  DL.  If  a  DR  is  deleted, 
its  position  in  the  initial  DBA  DL  is  set  to  zero  and  the  label  is  set 
to  "(1TJUSED)"  in  the  directory  label  data  list. 

The  system  directory  is  not  owned  by  the  master  directory.  It 
has  no  owner,  but  it  can  always  be  addressed  since  it  always  begins  in 
record  3.  The  DRandDL  ranking  codes  are  both  one. 
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2-5 •  Record  One 


The  first  record  of  every  DB  file  is  reserved  for  DECS 
use.  The  variables  that  are  vritten  to  it  are  given  in  Table  II-3 
but  they  are  not  defined  here.  See  Section  VIII. 

2-6.  The  Available  Record  List. 

During  dynamic  use  of  a  data  base,  DL's  and  DR's  may  be 
shortened  or  deleted.  This  means  that  some  records  on  the  DB  file 
will  be  unused.  The  DECS  keeps  track  of  the  DEA's  of  these  records 
and  re-uses  them  when  nev  records  are  needed.  The  Available  Record 
List  (ARL)  is  an  IDL  whose  elements  contain  DBA's  of  these  available 
records.  The  ARL  belongs  to  the  system  directory  (Section  2— U  above). 

The  ARL  helps  to  keep  the  DB  file  smaller  by  re-using  unused 
space  which  cannot  be  returned  to  the  operating  system.  DBA'b  of 
available  records  are  added  and  removed  from  the  end  of  the  ARL. 


Table  II-3*  Variables  on  Record  One. 


NVRECD(l),  NWCPD,  NCDPD,  MXRD(l,-),  MXRD(2,-) ,  ALFHD 
MLDLAD,  MHDLAD,  TDLAD,  NWADD,  KARLD(1,-) 


3-0  RECORD  STORAGE  IN  CORE  MEMORY. 

3-1 .  The  Smoothed  Access  Frequency. 

In  order  to  reduce  the  number  of  disk  accesses,  the 
DBCS  computes  an  access  frequency  for  each  record,  and  then  keeps 
the  most  frequently  accessed  records  ir  core.  Since  patterns  of 
record  accessing  may  change  over  the  life  of  a  DB,  an  exponentially 
smoothed  access  frequency  is  calculated  and  used  as  the  basis  for 
core  residence  decisions.  In  order  to  explain  the  procedure  we 
need  several  mnemonics: 


SAF 

TDLAD 


ALPHD 


smoothed  accerr,  frequency  for  a  record 

the  cumulative  number  of  record  accesses 
for  all  records  in  the  data  base  since 
it  was  created 

exponential  smoothing  constant 
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TSLU 


for  a  particular  record],  the  value  of 
TDLAD  at  tho  time  its  BAF  vas  last 
computed  ! 

ASLU  -  the  number  of  accesses  to  a  particular 
record  since  its  SAF  vas  last  computed 

Hew  SAF's  are  computed  for  records  when  they  are  written  to  disk, 
read  from  disk,  and  periodically  (see  variables!  MHDLAD  and  MLDLAD  in 
Section  VIII)  while  resident  in  core.  The  expresssion  ASLU/(TDLAD-TSLU) 
evaluated  for  a  particular  record  is  the  frequency  that  the  record 
was  accessed  since  its  last  SAF  update.  Approximate  formulas  for 
updating  SAF  are  given  below. 


Periodic  Update  in  Core 


(l-ALFHD)*SAF 


Afteif  Heading  from  Disk 


(i-.-iphd)wo14  ♦  alehd*!^ 

-TSLU^ 


Before  Writing  to  Disk 


(l-ALFHD)»SAFola  ♦ 


The  formulae  are  approximate  because  TDLAD -TSLU  is  not  the  same  at  every 
update  for  every  record.  To  compensate  for  this,  the  second  term  is 
weighted  for  the  average  update  period  in  the  formula  for  reading  and 
writing  from/to  disk.  SUBROUTINE  SAFD  contains  the  details. 

* 

Every  record  in  core  (whether  it  has  been  resident  for  some  time 
or  has  just  been  read)  has  a  SAF  value  which  is  approximately  comparable. 
In  other  voids,  it  represents  the  smoothed  access  frequency  of  the  record 
based  upon  nearly  the  same  criteria.  The  DBCS  uses  these  values  to 
determine  which  (records  will  have  a  tendency  to  be  retained  in  core. 


The  Internal,  Temporary,  and  Working  Stores. 


The  DBCS  has  two  large  core  storage  areas,  one  for  numeric 
data  and  one  for  character  data,  in  which  data  records  are  stored.  The 
character  storage  is  in  a  single  CHARACTER  variable  named  CSTORD. 
numeric  data  is  stored  in  a  one  dimensional  array  named  STORD  and  KSTORD 
(the  two  names  are  assigned  with  the  EQUIVALENCE  statement).  Each  of 
these  storage  areas  are  partitioned  into  areas  that  provide  three  main 
types  of  storage  for  the  DBCS. 


The  Internal  Store  (IS)  (actually  there  are  two,  a  character 
internal  store  and  a  numeric  internal  store)  ife  storage  used  in  a  tran¬ 
sient  manner  by  the  DBCS.  No  records  remain  in  IS  space  after  the 
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immediate  operation  vbich  the  DEC?  is  performing  is  completed.  A 
stack  of  IS  records  slots  is  maintained  and  allocated  to  DBCS 
processes  vhen  needed.  These  processes  then  return  the  slot  when 
done  with  them. 

The  two  other  areas,  the  Temporary  Store  (TS)  and  Working  Store 
(WS),  are  where  the  DBCS  stores  records  se^. -permanently,  and  it  is 
in  these  areas  that  the  SAF  is  significant.  When  a  request  is 
made  for  a  recox'd  that  is  not  in  core,  it  is  read  into  the  TS.  This 
means  that  a  record  in  the  TS  may  have  to  be  over-written.  If  so, 
the  one  with  the  lowest  SAF  (usually)  is  selected.  The  record 
remains  in  the  TS  and  may  be  accessed  again  while  there.  Peri¬ 
odically  the  DBCS  recomputes  SAF's  for  all  records  in  the  TS  and  WS. 
Any  record  in  the  TS  with  a  SAF  larger  than  the  minimum  SAF  in  the 
WS  is  swapped  into  the  WS.  Thus  records  which  are  accessed  fre¬ 
quently  will  appear  in  the  TS  frequently  and  will  eventually  migrate 
to  the  WS  where  they  have  a  high  degree  of  core  residence  persis¬ 
tence. 


One  exception  to  the  above  description  occurs.  The  DBCS  allows 
two  data  base  files  to  be  accessed  simultaneously.  They  are  re¬ 
ferred  to  as  the  Working  data  base  and  the  Reference  data  base.  The 
DBCS  assumes  that  the  reference  DB  is  to  be  used  only  to  copy  infor¬ 
mation  to  and  from  the  working  DB.  It  assumes  that  the  application 
program  performs  its  main  data  transactions  with  the  working  DB. 
Therefore,  SA-F's  are  never  re-ccmputed  for  reference  DB  records,  and 
reference  DB  records  are  never  moved  into  the  working  store.  They 
may  exist  only  in  the  temporary  store.  All  DBCS  functions  may  be 
performed  on  the  reference  DB,  but  because  of  the  above  restrictions, 
they  will  usually  execute  much  slower  than  equivalent  operations  on 
the  working  DB. 

3-3.  Structure  of  CSTORD  and  KSTORD/STORD. 

The  KSTORD/STORD  is  partitioned  into  nine  sections.  An 
array,  KNPD,  with  nine  elements  contains  pointers  to  the  first  element 
of  each  section.  In  other  words,  KNP.0(6)  is  the  first  element  of  the 
sixth  section  of  KSTORD.  The  data  stored  in  each  section  are  shown 
in  Table  II-U. 

Similarly,  the  data  stored  in  the  character  variable,  CSTORD, 
is  partitioned  by  an  array  KCPD  with  three  elements.  Table  11-5 
shows  the  CSTORD  position.  In  this  case,  KCPD(i)  is  the  first 
character  position  in  CSTORD  of  section  i. 

Before  describing  the  structure  in  each  section  of  the  storage 
areas  we  need  to  define  the  Data  Base  Control  System  Address  e-  DBCSA. 
When  a  record  is  read  into  core  storage,  its  control  part  is  stored 
somewhere  in  KSTORD.  The  element  of  KSTORD  where  the  first  word  of 
the  control  part  is  stored  is  its  DBCSA.  This  is  in  contrast  to  the 
data  base  address,  or  DBA,  discussed  earlier  which  is  the  record's 
address  on  the  data  base  file  (i.e.,  on  disk). 
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In-core  storage  for  the  Internal  Store  is  shown  in  Figure  II-5- 
Section  one  of  KSTORD  is  partiioned  in  segments  wixh  two  more  elements 
than  the  length  of  the  control  part.  As  specified  above,  the  DBCSA 
is  the  first  element  of  the  control  part.  An  "in-use"  indicator 
specifies  whether  this  record  storage  area  is  currently  being  used 
or  if  it  is  available  to  be  used.  Finally,  a  pointer  to  the  first 
character  of  the  data  part  that  corresponds  to  this  control  part  is 
also  stored  in  KSTORD. 

Section  5  of  KST0RD/3T0RD  is  partitioned  into  segments  to  hold 
the  control  part,  the  data  part,  and  one  extra  word  ■(which  is  the 
in-use  indicator)  of  the  numeric  internal  store. 

The  storage  scheme  for  the  character  TS  and  WS  is  shown  in 
Figure  II-6.  Storage  for  the  numeric  TS  and  WS  is  shown  in 
Figure  II-7-  The  main  difference  is  that  the  character  data  part 
is  stored  in  CSTORD,  and  a  pointer  to  the  data  part  is  maintained 
ir.  KSTORD.  The  SAF  and  ASLU  values  for  the  in-core  records  is 
stored  for  use  in  updating  the  SAF.  Also,  a  indicator  of  the 
DB  (working  or  reference)  is  maintained. 

The  predecessor  and  successor  DBCSA's  need  explanation.  As 
discussed  previously,  records  of  data  lists  and  directories  are 
linked  on  the  DB  file  by  predecessor  and  successor  DBA’s.  In  a 
similar  way.,  those  records  that  belong  to  a  particular  record  chain 
(a  DL  or  DR)  that  are  simultaneously  in  core  are  linked  by 
their  DBCSA's.  For  example,  suppose  a  data  list  has  four  records. 

On  disk,  the  DBA  chain  links  the  first  to  the  second,  the  second  to 
the  third,  and  so  on.  Suppose  at  seme  time  only  the  first  and 
third  records  of  the  DL  are  both  in  core.  The  DBCSA  chain  in  the 
TS  and  WS  would  link  the  first  to  the  third.  It  is  important  to 
understand  that  the  on-disk  DBA  chain  and  the  in-core  DBCSA  chain  are 
different.  The  DBCSA  chain  may  not  include  some  records  in  the  DBA 
chain.  The  DBCS  uses  the  DBCSA  pointers  to  keep  track  of  those 
records  which  belong  to  the  same  directory  or  d£:ta  list. 

Finally,  the  structure  of  the  ARL  storage  is  shown  in  Figure 
II-8.  Only  a  single  record  of  the  ARL's  for  the  working  and  refer¬ 
ence  DB's  are  stored  in  core.  Thus,  the  ARL's  are  handled  somewhat 
differently .than  other  DL's.  Section  8  of  KSTORD/STORD  is  dedicated 
to  the  core  storage  for  these  records. 

The  size  of  the  arrays  KSTORD/STORD  and  CSTORD  and  the  amount 
of  storage  allocated  to  their  various  partitions  is  controllable  by 
the  user.  The  procedures  for  doing  so  are  contained  in  Section  VI. 
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Figure  II-5-  Core  Storage  for  the  Internal  Store. 


CSTORD  (Section  2  or  3) 


0) 

<u 

u 

a> 

4-> 

c 

c 

o 

-a 

00 

c 

a. 

a> 

3 

00 

n 

a;  ^ 

T* 

o 

4-3 

00  ZD 

c 

00 

00  _ t 

2 

(0 

QJ  UQ 

4- 

U  < 

a> 

•r- 

U  ' — 

K1 

4-> 

tv 

tv 

0) 

2 

4-  4-> 

*r 

0) 

Ll. 

o  tv 

O') 

N 

< 

*3 

o 

C/) 

1 

t-  CL 
<U  3 

s 

< 

h- 1 

JQ 

CO 

E  Li. 

& - 

o 

3  < 
c  co 

o 

00 

g 

</> 

OJ 

s. 

_ 1 

u 

o 

8  0 
c 


v>  • 
</>  oo 

cu  c 

U  T- 

<D  JX 

“O  5- 

£  § 

Q. 

I 


KSTQRD/STORD  (Section 


KSTORD/STORD  (Section  8) 


ront'.’o'i  data  control  dita 


working  DB  reference  DB 


Figure  II-8.  Core  Storage  of  the  ARL. 


U-0  DBCS  PROTECTION  MODES. 

U-l .  Reed/Write  Protection  Modes. 


Each  data  base  (working  and  reference) has  a  user  assigned 
read/vrite  protection  mode.  The  available  modes  are  explained  In 
Table  11-6.  For  mode  1,  no  changes  are  permitted  to  the  DB.  The 
DBCS  itself  may  change  control  information  on  the  DB  file,  but 
the  user  may  net  change  data  in  the  DB. 

There  are  three  write  modes  that  trade  off  increasing  access 
speed  with  safety.  With  mode  2  eve'-y  change  to  the  data  base  is 
immediately  written  to  disk,  so  the  DBF  is  always  current.  This  is 
the  safest  but  also  the  slowest  access  method.  With  mode  3,  changes 
to  data  lists  are  not  written  to  disk  until  the  record  in  which  the 
change  occurs  is  removed  from  core  (i.e.,  bunped  from  the  temporary 
store).  Thu3,  the  DB  can  be  out  of  date  while  an  application  pro¬ 
gram  is  running.  The  structure  and  integrity  of  the  DB  is  always 
protected,  however.  This  mode  provides  substantial  speed  advantages 
over  mode  2  when  active  reod/write  activity  is  performed  cn  many 
data  lists. 

Mode  U  is  similar  to  mode  3  except  that  even  data  necessary  to 
protect  the  integrity  of  the  DBF  is  not  written  to  core  until 
absolutely  necessary.  If  an  abnormal  termination  of  the  program 
occurs  while  in  this  mode,  portions  of  the  DBF  may  not  be  recover¬ 
able. 
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Table  II-6.  Read/Vrite  Protection  Modes 


Mode  Value 

Meaning 

1 

Read  Only 

2 

Write-Safe.  The  DB  may  be  changed,  and 
every  change  is  Immediately  written  to  disk. 

3 

Write-Lco3e.  The  IB  may  be  changed,  but 
only  data  needed  to  protect  the  integrity 
of  the  DB  is  vritten  to  disk  immediately 
as  it  occurs.  Changes  to  data  lists  may 
exist  only  in  core  and  the  disk  record  will 
he  updated  only  when  the  record  is  removed 
flea  core  storage.  In  case  of  abnormal 
termination,  sane  data  lists  may  lose 
information. 

Vrito-Unsafe.  The  DB  may  be  changed,  but 
no  data  is  written  to  disk  unless  absolutely 
necessary.  If  abnormal  termination  occurs, 
the  structure  of  the  data  base  may  be 
flawed  and  irrecoverable. 

When  a  DBF  la  first  created  by  the  BBSS,  it  has  mode  1.  The 
user  may  change  the  mode  as  often  as  desired  with  a  subprogram  call 
(see  Section  VI). 

U-2.  Force  Read/Write  Flags. 


Because  of  the  read/vrite  protection  modes  described 
above,  it  is  possible  for  a  data  list  record  in  core  to  be  different 
from  the  corresponding  disk  record.  Each  subprogram  which  accesses 
data  list  information  has  force  read  or  force  write  flag  as  one  of 
its  parameters. 

If, when  writing  information  to  a  data  list,  the  force  vrite  flag  is 
"on"  then  the  effected  records  will  immediately  be  written  to  disk. 

This  emulates  mode  2  for  one  vrite  access  only.  In  this  way,  it  is 
possible  to  treat  certain  data  lists  as  though  mode  2  were  in  effect 
when,  in  fact,  the  true  mode  is,  say,  3.  Rote,  however,  that  the 
force  write  flag  does  not  override  mode  1. 
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Similarly,  when  reading  from  a  DL,  a  force  read  flag  may  be 
turned  "on"  which  causes  the  record  to  be  reed  from  disk  even  if 
the  record  13  resident  in  the  TS  or  WS.  This  disk  read  will  over¬ 
write  the  in-core  version  if  there  is  one.  If  the  DB  is  in  mode 
3  or  It,  then  the  in-core  version  of  a  DL  record  might  contain 
information  different  than  that  r.n  disk.  Using  the  force  read 
flag  in  this  case  will  cause  the  in-  core  version  to  become 
identical  to  the  disk  version,  and  a  DBCS  error  code  7  will 
result  (see  Section  VII).  This  does  not  terminate  execution, 
but  it  warns  the  user  that  information  has  been  lost. 
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III.  OVERVIEW  OF  THE  FLOW  OF  CONTROL 


1- 0  GENERAL  DESCRIPTION. 

The  DBCS  is  a  collection  of  subprograms  which  an  application 
program  may  use  to  create  and  manipulate  a  data  base  file.  The 
DBCS  has  no  main  program,  so  it  has  no  stand  alone  capability. 

It  was  designed  to  provide  rapid  access  to  data  for  the  HOPADS 
system.  The  DBCS  can  be  used  in  settings  other  than  HOPADS, 
because  it  has  no  built  in  structure  that  is  unique  to  HOPADS. 

It  does  not,  however,  have  many  traditional  data  bdse  features 
because  of  its  specialized  target  environment.  It! also  imposses 
a  somewhat  greater  burden  on  application  programs  than  other 
similar  data  base  systems.  The  DBCS  requires  the  application 
program  to  remember  DB  address  information  vblch  1b  used  by  the 
DBCS  to  implement  fast  data  access  (see  Sections  V  and  VI). 

2- 0  DBCS  FUNCTIONS. 

The  DBCS  provides  capabilities  to  perform  the  following 
functions  on  DB  files: 

1.  Open/Close  DB  Files 

2.  Add/Delete/Rename  Directories 

3.  Add/Deiete/Extend/Shorten  Data  Lists  * 

f. 

1».  Read/Write  Data  Lists 

5-  Set /Change  the  DB  Protection  Mode 

6.  Search  Directories  for  Particular  DL'si  or  DR'a 

7.  Set /Ac cess /Change  Labels  of  Data  Lists ■ and 

Data  List  Elements 

8.  Read/Write  External  Format  Data  Files  for 

Portability  of  DB  Files 

9*  Set/Access  Various  DBCS  Options 

10.  Print  Contents  of  DL'!  and  DR’s 

All  of  these  functions  are  described  in  greater  detail  in 
Section  VI. 

3- 0  DATA  BALE  ACCESSES. 

The  most  frequent  operation  performed  on  the  data  base  is  to 
store  or  retrieve  data  from  a  data  list.  A  schematic  of  this  pro¬ 
cess  is  shewn  in  Figure  I1I-1.  A  variety  of  subprograms  are 


represented  by  this  diagram  since  separate  snbpiogr'jss  are  used 
depending  upon  whether  the  operation  is  a  read  or  write,  the  DL 
is  one  or  two  dimensional,  and  the  data  type  of  the  DL.  Figure 
III-l  is  typical  for  all  cases,  however. 

Virtually  an  user  callable  DBCS  subprograms  have  error 
trapping  features.  These  are  represented  generically  in  box  1 
of  Figure  III-l.  The  next  step  is  to  determine  the  elements,  LI 
to  L2,  of  the  data  list  that  are  desired.  Note  that  these  elements 
may  cross  record  boundries.  In  other  words,  seme  of  the  elements 
may  be  in  one  record  and  some  on  subsequent  records.  In  the  case 

of  two  dimensional  DL's,  this  step  involves  decoding  the  structure 

of  the  DL  so  it  can  be  treated  as  a  one  dimensional  DL. 

The  workhorse  of  DB  accessing  is  SUBROUTINE  LOCRD.  It's  pri¬ 
mary  activity  is  to  locate  records  in  core  which  contain  elements 
in  the  interval  LI  to  L2.  The  user  will  have  passed  a  data  base 
address  (to  be  described  in  Section  VI )  which  will  point  directly 
to  a  record  of  the  DL  in-core  if  the  normal  dynamic  core  memory 

management  has  not  moved  it.  If  this  is  the  case,  block  3  (SUB¬ 

ROUTINE  FINDLD)  is  trivial.  If  the  DL  record  has  been  moved, 

FINDLD  will  find  it  again  (or  read  it  from  disk  if  needed). 

At  block  1«,  LOCRD  will  search  the  in-core  record  chain  for 
elements  in  [L1,L2  ].  If  the  required  elements  are  not  found 
(block  5),  SUBROUTINE  GETRCD  will  be  called.  When  GETRCD  is  called, 
LOCRD  has  identified  the  exact  record  which  will  contain  the 
desired  elements.  Only  a  single  block  represents  GETRCD,  but  in 
fact  it  performs  an  important  function.  GETRCD  and  the  subprograms 
it  calls  are  responsible  for  all  of  the  dynamic  memory  management 
of  the  TS  and  WS.  It  is  in  these  subprograms  that  SAF's  are 
checked  and  updated  and  that  records  migrate  from  the  TS  to  the  WS. 
On  return  from  GETRCD,  the  record  is  in-core.  LOCRD  repairs  the 
in-core  record  chain  (block  7). 

At  block  8,  LOCRD  sets  II  and  12  to  the  element,  numbers  (a 
subset  of  [L1,L2]  that  are  contained  ir  the  r<>«ord  it  has  found.  The 
calling  program  accesses  these  elements  (i.e.,  write  to  or  copies 
from  them) (block  9)»  then  it  determines  if  all  of  the  elements  LI  to 
L2  have  been  accessed  (block  10).  If  not,  LOCRD  is  called  again  to 
find  another  record  with  more  of  the  desired  elements. 

When  frequently  accessed  records  that  are  in  the  working 
store  are  being  requested,  the  step  at  block  3  is  trivial  and 
GETRCD  is  not  called.  All  other  operations  in  LOCRD  are  simply 
stepping  through  a  linked  list  of  records  in-core  which  is  quite 
fast.  The  result  is  that  data  base  accesses  from  records  in  the  WS 
or  TS  are  relatively  fa3t. 
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Access  of  data  in  ulractories  is  handled  in  Lit  tame  ir»;r  since 
uli  act  cries  are  two  -’imensionol  DL's  and  are  stored  in  the  v?S  and  73 
in  the  sane  way  thf-t  data  lists  are. 

4- C  THE  DBCS  ixhj  MOPADS. 

The  MOPADS  data  base  is  the  main  repository  of  information  for 
MCPATj  simulations.  It  maintains  the  simulation  data  set  prior  to  rVr 
lali yi  irons ,  the  dynamic  siirilati.on  state  during  simulations,  and 
r<.j’itt  statistics  after  sirulations  are  completed.  Therefore,  vho 
DECS  is  a  hey  module  during  all  phases  of  MOPADS  operation.  Figure 
U:i-2  it  schematic  of  the  1-0  "AES  modules  which  call  the  The 

EBAP  (Data  Base  Application  T-To(vams  ( MOPADS /D'AP) )  is  a  collection  c  ■' 
program  utilities  designed  especially  fcr  manipulation  of  the  MOPADS  DB 
(Polito  (1983b)  ).  The  DBCS  is  required  for  both  batch  Job  simulations 
of  an  defense  system  and  for  interactive  user  interface  sessions. 

5- 0  UTILITIES. 

The  DBCS  makes  extensive  use  of  programs  from  the  MOPADF 
utilities  module  (Polito,  Goodin). 


Figure  III-2.  DBCS  and  MOPADS. 


IV.  EXTERNAL  FILE  USAGE 


1- 0  DATA  BASE  FILES. 

The  DBCS  may  simultaneously  access  two  DBF's.  These  files 
are  opened  and  closed  explicitly  with  FORTRAN  OPEN  end  CLOSE 
statements.  By  default,  the  DBCS  uses  on  it  number  one  for  the 
working  DB  and  uni-  number  two  for  the  reference  DB.  These  unit 
numbers  may  be  changed  by  the  user,  howe\er. 

Data  base  files  have  the  following  characteristics: 

1.  Direct  Access 

2.  Unformatted 

3.  Fixed  Record  Length 

The  record  length  is  selectable  by  the  user.  The  user  gives  the  DB 
file  names  to  the  DBCS  and  they  are  opened  with  the  specified  unit 
number.  No  Job  control  language  is  needed  to  assign  the  unit 
number  to  the  file  unless  required  by  the  computer  system.  > 

2- 0  OUTPUT  AND  TRACE  FILES . 

The  DBCS  will  produce  certain  output  and  trace  information  on 
request.  Two  files,  an  output  and  a  trace  file  are  used  for  this 
purpose.  By  default,  unit  number  ten  is  used  for  both  of  these 
files.  The  unit  number  is  user  selectable,  however,  and  need  not  be 
the  same  for  both  files.  These  files  have  the  following  character¬ 
istics: 

1.  Formatted 

2.  Sequential 

They  are  not  rewound  by  DBCS,  so  both  files  may  refer  to  an  inter 
active  terminal.  Carriage  control  characters  are  included  on  these 
files  so  they  may  be  listed  at  a  line  printer. 

The  DBCS  does  not  open  or  close  these  files.  They  must  be 
opened  and  closed  by  the  application  program  or  assigned  to  the 
correct  unit  numbers  by  appropriate  job  control  language  statements. 

3- 0  BACK-UP  FILES. 

The  DBCS  provides  two  mechanisms  for  backing  up  data  base  files 
on  magnetic  tape  ana  for  transferring  data  base  files  from  one  com¬ 
puter  to  another.  DBF's  are  unformatted,  direct  access  files.  Some 


systems  may  not  permit  these  files  to  he  copied  directly  onto  a 
magnetic  tape  in  a  way  which  preserves  their  integrity.  The  DBCS 
has  a  utility  which  will  allow  the  application  program  to  write  a 
DBF  to  a  "sequential,  internal  format"  file.  This  file  13  a  sequen¬ 
tial,  unformatted,  fixed  record  length  file  which  may  he  copied  to 
tape.  These  files  may  also  he  read  from  tape  and  a  normal  DBF  file 
re-created. 

Since  unformatted  files  cannot  usually  he  transferred  from  one 
type  of  computer  to  another,  the  DBCS  also  has  the  ability  to  write 
the  DBF  to  a  "sequential,  external  format"  file  which  is  a  sequential 
formatted  file  with  80  characters  or  less  per  record.  Thus,  DBCS 
data  base  files  are  portable  from  one  computer  to  another. 

The  user  has  total  responsibility  to  open,  close,  and  assign 
unit  numbers  to  these  files.  No  defaults  art  provided.  The  user 
passes  the  unit  number  to  the  D3CS.  The  DBCS  will  generate  an  error 
if  the  required  operations  cannot  be  performed  on  the  file. 
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V.  SUBPROGRAM  DESCRIPTIONS 


The  following  pages  contain  description  of  all  sub¬ 
programs  that  are  part  of  the  DBCS.  Each  program  description 
contains  an  explanation  of  its  purpose,  parameters,  and  alter¬ 
nate  returns.  No  examples  of  subprogram  use  are  contained  in 
this  section,  since  user  instructions  are  given  in  Section  VI. 

The  DBCS  makes  extensive  use  of  the  MOPADS  utility  sub¬ 
programs  described  in  Polito  &  Goodin  (1983).  Also,  the  MOPADS 
module  suffix  for  the  DBCS  is  "C" ,  so  all  DBCS  subprogram  names 
end  with  the  letter  "D". 
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SUBROUTINE  ARISD (IOPT , IDBCSA, IERR , * ) 

—MODULE:  HOPADS/DBCS 
--REFERENCE:  M0PAD3  VOLUME  5.13 
—PURPOSE: 

ARISB  allocates  and  de-allocates  elements  of  the  internal  store 

FOR  INTERNAL  DBCS  USE.  ! 

—INPUT  PARAMETERS:  I 

IOPT-OPTION 

1- ALLOCATE  NUMERIC  IS  I 

2- DE-ALLOCATE  NUMERIC  IS 

3- ALLOCATt  CHARACTER  IS 

4- DE-ALLQCATE  CHARACTER  IS 

—INPUT/OUTPUT  PARAMETERS:  ! 

IDBCSA(2)  — DBCSA'j.  ,  j 

*  FOR:  f  I  1 

1NPUT-I0PT=2,  DE-ALLOCATE  THE  RECORD  DF  THE  IS  WHOSE 

CONTROL  PART  STARTS  AT  LOCATION  IDBCSAP). 
IDBCSA  SET  TO  ZERO  ON  RETURN. 

IOPT-4,  DE  ALLOCATE  THE  RECORD  OF  THE  CHARACTER  IS 
THAT  HAS  ITS  CONTROL  PART  STORED  AT 
IDBCSA(i)  AND  ITS  DATA  PART  AT  IDBC5A(2> 
IDBCSA  SET  TO  ZERO  ON  RETURN. 
QUTPUT-IOPT--1,  IDBCSA(1)=PQSITI0N  IN  THE  DATA  STORE  OF 
THE  1ST  UORD  OF  THE  CONTROL  PART. 

IDBCSA ( 2 )  IS  THE  POSITION  OF  THE  FIRST 
UORD  OF  THE  DATA  PART. 

I0PT--3,  IDBCSA11  )*rOSITIQN  IN  THE  DATA  STORE  OF 
1ST  UORD  OF  THE  CONTROL  PART.  IDBCSA12) 

IS  THE  CHARACTER  POSITION  IN  CSTOR  OF  THE 
DATA  PART. 

-OUTPUT  PARAMETERS: 

IERR-ERROH  CODE 
O-NO  |ERR3R 

4003-INTERNAL  STORE  EXHAUSTED 
C— ALTERNATE  RETURNS: 

C  1-IERR.NE.O 

C 


SUBROUTINE  ASKD(NPB,ICPK) 

C— HODULE:  M0PADS/DBC3 
C — REFERENCE*  HQPADS  VOLUME  5.13 

C--PURPOSE:  I 

C  ASK'D  UILL  DETERMINE  IF  A  UORKING  OR  REFERENCE  DB  IS  OPEN. 
C 
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I  —INPUT  PARAMETERS: 

C  NDB-DB<1-U0RKING, 2-REFERENCE) 

C— OUTPUT  PARAMETERS: 

C  IOPN-DB  STATUS 

C  1-OPEN 

'C  2— CLOSED 

C 


BLOCK  DATA  BLOCKD 
C— NODULE:  NOPADS/DBCS 
C— REFERENCE:  HOPADS  VOLUME  5.13 
C— PURPOSE: 

C  TO  INITIALIZE  LABELED  COMMON 


SUBROUTINE  3RACKDO.DB , NRANK , IUAL, IDRDL, ID30, ISH , ISL2,NTY,IERR 

C— MODULE:  MOPADS/DBCS 
C — REFERENCE:  MOPADS  VOLUME  5.13 
C— PURPOSE: 

C  BRACKD  IS  A  UTILITY  PROGRAM  CAL’  ED  ONLY  BY  1NSDRD. 

C  IT  UILL  FIND  COLUMNS  ISL1  AND  I.L2  IN  A  DR(IDBQ)  THAT 

C  BRACKET  A  SPECIFIED  VALUEUVAl.)  OF  THE  NRANK-TH 

C  ELEMENT  OF  DR'S  OR  DL'S  OWNED  BY  IDBQ. 

C  THE  PUSH  ION  OF  IDBO  IS  NOT  CHANGED. 

C 

C— INPUT  PARAMETERS: 

C  NDB-DATA  BASE! I -WORKING, 2-REFERENCE) 

C  NRANK-THE  RANKING  CODE  FOR  Th’E  V'(IDBO)  FOR  THE  CORRECT  TYPE. 

C  IF  NRANK=0,  MTY  13  RETURN  ?  AS  AN  EMPTY  COLUHN. 

C  IVAL-THE  VALUE  OF  THE  f.3S(NRANK)-TH  ID  ELEMENT  TO  BRACKET. 

C  IDRDL-TYPE 

C  1-DP'S 

C  2-DL'S 

C— INPUT/OUTPUT  PARAMETERS: 

C  ID80(4)-DRAA  OF  THE  DR.  IT  MUST  BE  CURRENT. 

C— OUTPUT  PARAMETERS: 

C  ISL1 ,ISL2-C0LUMNS  ISL1  AND  ISL2  UILL  BRACKET  IVAL. 

C  LET  ID1  BE  THE  IDENTIFIER  AT  CULUMY  ISL1. 

C  SIMILAR  FOR  ID2.  LET  lRANKeAB5<NRANX ) .  THEN 

C  ON  RETURN, 

C 

C  ISL1.LE.ISL2 

C  IDI(IRANK). LE.1VAL.LT. 1021 1 RANK )  IF  NRANK. GT.O 

C  IDlURANK).GE.IVAL.nT.iD2(IRMRK)  IF  NRANK. LT.O 

C  IF  UL1*0  AND  ISi.2.NE.O,  ISL2  IS  THE  FIRST  COLUMN 


C  IN  THE  DR  OF  TYPE  IDRDL. 

C  ir  1SU.NE.0  AND  1SL2=0,  ISU  JS  THE  LAST  COLUHN 

C  IN  THE  DR  OF  TYPE  1DR3L 

C  IF  ISL1 “!SL2*0,  THEN  NRANK=0  OR  NO  ENTITIES 

C  IDF  TYPE  1DRBL  EXIST. 

C  HTY-THE  COLUHN  NUMBER  OF  AN  EMPTY  COLUMN  "NEAR"  ISL1  AND  ISL2. 

C  IF  ISL1  =  ISL2*=0,  HTY  IS  STILL  AN  EMPTY  COLUMN. 

C  IESR-ERROR  CODE 

C  O-NO  ERROR 

C— ALTERNATE  RETURNS* 

C  1-IERR.NE. 0 

C 


SUBROUTINE  CHAIND<NDB,IOPT,IDBO,IDBN,IERR,*) 

C— MODULE:  MOPADS/DBCS 
C— REFERENCE:  NOPALS  VOLUME  5.13 
C—  PURPOSE: 

C  CHAIND  LINKS  AND  UNLINKS  RECORD  CHAINS  ON  THE  DISK. 

C  IT  CHANGES  ONLY  THE  PREDECESSOR  AND  SUCCESSOR  RECORD 

C  NUMBERS  IN  THE  CONTROL  PARTS.  IT  CHANGES  NO  LINKING 

C  INFORMATION  !N  THE  DATA  STORE. 

C— INPUT  PARAMETERS: 

C  NDF -DBFn-UORKING, 2-REF) 

C  IOPT-0PTIOM 

C  1-LINK  1DBH  BEFORE  IDBO 

C  2-LINK  ISBN  AFTER  IDSO 

C  3-UNLINK  TDBO„  ISBN  NOT  USED. 

C  IDI0(2>-DBC5A'A  OF  THE  RECORD  TO  LINK  TO(OR  UNLINK). 

C  IDBOm-CONTROL  PART,IDBO<2)-LATA  PART 

C  IDINC  2I-DBC5A' A  OF  THE  RECORD  TO  BE  LINXED.  CHAIND 

C  ASSUMES  IDBN  IS  OF  THE  SAME  TYPE  AS  IDBO. 

C  IDIN( 1 )-CONTRQL  PART,IDB«(2)-DATA  PART. 

C--OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  1 ,2,3004,4002, 4004, <005 

C-AITERNATE  RETURNS: 

C  1-IERR.NE. 0 

C 


SUBROUTINE  C!IECKD<ICODE,KPAR,NK,PAR,NP,IERR,») 

C— MODULE:  H0PADS/D3CS 
C— REFERENCE:  MOP  ADS  VOLUME  5.13 
C— PURPOSE: 

C  TO  CHECK  STANDARD  ERROR  CONDITIONS  AND  RETURN 
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C  THE  APPROPRIATE  ERROR  CODE.  CHECKD  DOES  NOT  CALL 

C  ERRORD. 

C— INP’JT  PARANETERSi 

C  ICODE-ERROR  CONDITION  TO  CHECK  FOR.  IF  ICODE 

C  IS  INVALID,  RETURN  UITH  IERR=0. 

C  ICODE  CONDITION  ERROR  CODE 


C 

C 

C 

C 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c- 

c 

c 

c- 

c 

c 


1  UORKINKQ  DATA  BASE  NOT  OPEN  1 

2  REFERENCE  DATA  BASE  NOT 

OPEN  2 

3  DB;  (KPARID)  >0  OR 

6REATER  THAN  USED  SO  FAR  4 

4  SANE  AS  3  BUT  IN  SERIOUS 

SITUATION  4005 

5  CHECK  VALID  DL  OR  DR 
ELEMENT  NUMBER.  KPAR(I). 

LT.KPAR(O) .OR.KPAR(O) 

•LE.O  5 

A  CHECK  SUFFICIENT  SPACE 

IN  KUORKD  ARRAY.  4009 

7  DB  IS  READ  ONLY.  KPAR(0)=DB 

NUMBER  (1  OR  2)  8 

KPAR(NK»-LIST  OF  INTEGER  PARAMETERS  TO  IE  USED  TO 
CHECK  THE  ICODE  CONDITION.  IF  MK*0,  NONE. 
PAR(NP)-LIST  OF  REAL  PARAMETERS  TO  IE  USED  TO  CHECK 
THE  ICODE  CONDITION.  IF  NP=0,  NONE. 

-OUTPUT  PARAMETERS: 

IERR-ERROR  CODE  FOR  THE  ICODE  CONDITION  IF  IT  IS  TRUE. 
ZERO  IF  NOT. 

-ALTERNATE  RETURNS: 

1-JF  IERR-0  (l.E.  NO  ERROR) 


SUBROUTINE  CLEARDINDB, IERR,* ) 

C— MODULE:  NOPADS/DICS 

C— REFERENCE:  NOPADS  VOLUME  5.13 

C--PURPOSE: 

C  TO  CLEAR  THE  US  AND  TS  OF  ENTRIES  OF  THE  INDICATED  DB. 

C  THIS  RAT  IE  DONE  UHEN  A  DIFFERENT  SET  OF  DATA  LISTS 

C  IS  TO  IE  ACCESSED  OR  UHEN  A  NEU  DD  IS  TO  BE  OPENED. 

C  — INPUT  PARAMETERS: 

C  NDB-DATA  SASE(C-I0TH,1-U0RKIND, 2-REFERENCE) 

C  — OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  .NE.O-ERRCR  WRITING  TO  DIF 


C— ALTERNATE  RETURNS! 
C  1—1  ERR . NE .  0 

C 


SUBROUTINE  CLRDUHNDB, IDRAA, 1ERR,*) 

C--MODULE:  HOPADS/DBCS 

C— REFERENCE!  HOPADS  VCLUHE  S.13 

C--PURPOSE: 

C  CLRDLD  UILL  DELETE  ALL  DL'S  FROM  A  DIRECTORY. 
C 

C~  INPUT  PARAMETERS! 

C  NDB-DATA  BASE ( 1 -UORKING, 2-RETEREHCE > 

C— -INPUT/OUTPUT  PARAMETERS! 

C  IDRAAH>-DRAA  OF  THE  DIRECTORY  TO  CLEAR 

C 

C — OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C — ALTERNATE  RETURNS: 

C  1-IERR.NE.O 


SUBROUTINE  CLRDRDtKDB.IDRAA.IERR,#) 

C— MODULE:  HOPADS/DBCS 

C— REFERENCE:  HOPADS  VOLUME  5.13 

C--PURPOSE: 

C  CLRSRD  UILL  EMPTY  A  DR  OF  ALL  CQNTENTSCTHE  DR  IS  NOT 
C  DELETED, HOUEVER).  ALL  OUNED  DL'S  ARE  DELETED  AND  ALL 

C  OUNED  DR'S  (WITH  THEIR  CONTENTS)  ARE  DELETED. 

C--INPUT  PARAMETERS: 

C  NDB-SATA  BASE  I 1-UORKING, 2-REFERENCE) 

C--INPUT/OUTPUT  PARAMETERS: 

C  IDRAA1D-DRAA  OF  THE  DIRECTORY 

C— OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  15-IDRAA  NOT  A  DR 

C— ALTERNATE  RETURNS: 

C  l-IERR.NE.O 


SUBROUTINE  CLRDSD1NDB, IDBAA, IERR,*) 
C--MODULE:  HOPADS/DBCS 
C--REFEREHCE:  HOPADS  VOLUME  5.13 
C--PURPOSE: 
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c 
c 
c 

C--INPUT 


ID  CLEAR  «  RECORD  CHAIN  FROM  THE  DATA  STORE. 
THIS  PROGRAM  IS  USED  HAINLY  TO  REHOVE  LDL'S 
FROM  THE  DATA  STORE. 

PARAMETERS: 

C  NliB-DATA  DASEd-UORKINC, 2-REFERENCE) 

C — INPUT/QUTPUT  PARAMETERS: 

C  IDiAA(2)-DBAA  OF  ONE  RECORD  OF  THE  CHAIN. 

C  ON  RETURN  IDBAA(2>*0 

C— OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  {  O-NO  ERROR 

C  .NE.O-ERROR 

C— ALTERNATE  RETURNS: 

C  1-IERR.NE.O 


SUBROUTINE  CLSDBI<NDBtIST4T,IERR,IOERR,*) 

C— MODULE:  MOPADS/DBCS 
C— REFERENCE:  HOPADS  VOLUME  5.13 
C— PURPOSE: 

C  TO  CLOSE  A  DBF 

C— INPUT  PARAMETERS: 

C  NDB-DF{1 -HORNING  ,2-KEF) 

C  NO  ACTION  IF  THE  DB  IS  NOT  OPEN 

C  ISTAT-STATUSd-KEEP,  2-DELETE) 

C— OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  3004  SYSTEM  I/O  ERROR 

C  IOERR-SYSTEM  I/O  ERROR  CODE 

C  O-NO  ERROR 

C  SYSTEM  I/O  ERROR  NUMBER  IF  IERR»3004 

C-ALTERNATE  RETURNS: 

C  1-IERR.NE.O 


SUBROUTINE  CRDLD1 NDB, IT YPE,NDIH, LABEL, IGBO, IDBAA,IERR,*) 
C — MODULE:  MOPADS/DBCS 
C— REFERENCE:  MOPADS  VOLUME  5.13 
C— PURPOSE: 

C  TO  CREATE  A  DATA  LIST 

C 

C--INPUT  PARAMETERS: 

C  NJIB-DATA  BASEd-UCRXING,2-REFEnENCE) 

C  ITYPE-TYPE  OF  DATA  LIST 

C  I  1-IDL 

C  2-RDl 
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C  3-CDL 

C  ND1M-F0R  Ifll  AND  RDL,  THE  ROW  OR  COLUMN  DIMENSION. 

C  <♦)  VALUES-MAX  ROU  D1«ENSTQN(I.E.  COLUMN  ORIENTED) 

C  (-)  VALUES-iiAX  COLUMN  DIHETSIQNtl.E.  RO'J  ORIENTED) 

C  FOR  1-D  DATA  LISTS,  USE  J 

C  FOR  CDL,  THE  NUMBER  OF  CHARACTERS/ELEMENT. 

C  IF  NBiH.EQ.O,  A  VALUE  Or  S  UILL  BE  USED. 

C  LABEL- l CHARACTER)  LABEL  OF  THE  DATA  LIST (LIMITED  TO 
C  25  CHARACTERS).  IF  BLANK,  THE  LABEL 

C  '(UNLABELED)'  WILL  BE  USED. 

C— INPUT/OUTPUT  PARAMETERS: 

C  I310(4)-DRAA  OF  THE  OUNINS  DIRECTORY (CRDLD  DOES  NOT  INSERT 
C  THE  NEU  DATA  LIST  IN  THE  OUNINQ  DIRECTORY) 

C— OUTPUT  PARAMETERS: 

C  IDBAAO-DBAA  FOR  THE  NEU  DATA  LIST 

C  .  IERR-ERROR  CODE 
C  O-NO  ERROR 

C  3005-TRY  TO  CREATE  CDL  U1TH  TOO  MANY  CHARACTERS/ELEMEHT 

C— ALTERNATE  RETURNS: 

*  C  1-IERR.NE.O 


SUBROUTINE  CRDRB (HDI, HRBR, NRDL.NUID, LABEL, IDBO, It RAA,IERR,*> 
C — MODULE:  MOPADS/DBCS 
C— REFERENCE:  HOPADS  VOLUME  5.T3 
C— PURPOSE: 

C  TO  CREATE  A  DIRECTORY 

C 

C— INPUT  PARAMETERS: 

C  NBI-0ATA  iASE(1-UORKlNG, 2-REFERENCE) 

C  NRDR-RANKINO  CODE  FOR  OUNED  DIRECTORIES 
C  O-NOT  RANKED 

C  N-INCREASIHG  ORDER  OF  UORB  N  OF  THE  !? 

C  (-N)-DECREASING  ORDER  OF  UOf.B  N  OF  THE  ID 

*  C  NRDL-RANKING  CODE  FOR  OUNED  DL'S 
C  (THE  MEANINGS  ARE  THE  SAME  AS  FOR  NRDR ) 

C  NUID-HUMBER  OF  UORDS  PER  ID  FOR  OUKEB  PR'S  AND  DL'S 
C  LAE£L-( CHARACTER)  LABEL  OF  THE  DIRECTORY (LIMITED  TO 
C  AO  CHARACTERS).  IF  BLANK,  THE  LABEL 

C  '(UNLABELED)'  UILL  BE  USED. 

C— INPUT/OUTRUT  PARAMETERS: 

C  IDBOm-DRAA  OF  THE  OUNING  OIRECTORY(CRDRD  DOES  NOT  INSERT 
C  THE  NEU  DIRECTORY  IN  THE  OUNING  DIRECTORY) 
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C — OUTPUT  PARANETERS! 

C  IDR.YA<4)-DRAA  FOR  THE  NEU  DIRECTORY 

C  IERR-ERRCR  CODE 

C  O-KC  ERROR 

C  14-NRBR/NRDL  INCORRECT  OR  INCOMPATIBLE  UITH  nUID 

C—AUEkl.ltt  RETURNSs 
r.  1-IENR.NF.O 


SUBROUTINE  CURD(NDBf IDRDL,NIP,IBRAA.IBAA1 ,ID,IERR,*,*) 

C — MODULE  x  NDPADS/DBCS 
C — REFERENCE!  NOPADS  VOLUME  5.13 
C— PURPOSE* 

C  CURD  UILL  RETURN  THE  DBA  AND  ID  OF  THE  CURRENT  DL  OR  DR 
C  POSITION  OF  A  DIRECTORY. 

C— INPUT  PARAMETERS i 

C  KDB-DATA  IASEU -WORKING, 1- REFERENCE) 

C  IDRDL-POSITION  TYPE 

C  1-DR 

C  2-BL 

C  NID-LENGTH  OF  ID.  IF  N1D.LE.O,  ID  UILL  NOT  BE  USED. 

C— INPUT 'OUTPUT  PARANETERS! 

C  IBRAA<4>-DRAA  OF  THE  DIRECTORY 

C— OUTPUT  PARAMETERS! 

C  IDAA1-DSA  OF  THE  CURRENT  PETITION  OF  TYPE  IDR2JL. 


c 

IF  THE  DIRECTORY  IS  NOT  POSITIONED, 

,  IDAA1 

*0 

C 

AND  ALTERNATE  RETURN  1  IS  TAKEN. 

C 

IB(NIB)-THE  FIRST  NID  WORDS  OF  THE  IDENTIFIER. 

IF 

c 

NID.LE.O,  ID  IS  NOT  USED.  IF  ALTERNATE 

RETURN 

c 

1  IS  TAKEN,  IDO. 

c 

IERR-ERROR  COSE 

C 

O-NO  ERROR 

J 

C- 

-ALTERNATE  RETURNS! 

ii 

c 

1 -DIRECTORY  POSITION  OF  TYPE  IDRDL  IS  NOT 

'  DEFINED. 

c 

IDAA1 *0. 

c 

2-IERR.NE.O 

ii 

i 

SUBROUTINE  BBOPTDT I0PT , IP6,NIV,NRV, IVL.RVL, IERR,*) 

C— NODULEi  NCPADS/DBCS 
C— REFERENCE!  NOPADS  VOLUNE  5.13 
C— PURPOSE! 

C  DBOPTD  UILL  SET  OR  RETURN  THE  VALUES  OF  DBCS  OPTIONS  AND 

C  PARANETERS. 

C—  INPUT  PARANETERS! 

C  IOPT-OPTION  A UMB Eft < SEE  BELOU) 

C  IPG-PUT/GFT  FLAG 
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C  1-PUT  NEU  OPTION  VALUE 

C  2-RETRIEVE  OPTION  VALUE 

C--INPUT/OUTPUT  PARAMETERS} 

C  IVL(NIV)-ARRAY  TO  HOLD  INTEGER  VALUES 

C  RVL(NRV)-ARRAT  TO  HOLD  REAL  VALUES 

C— OUTPUT  PARAMETERS} 

G  IERR-ERROR  COSE 

C  O-NO  ERROR 

C  1 7-2 OPT  INCORRECT 

C  18-INVALID  UNIT  NUMBER 

C  IP-INSUFFICIENT  ROU/COLUMN  SPECIFICATION  ON  OUTPUT  FILE 

C  2004-UNIT  NUMBER  OF  AN  OPEN  DB  MAY  NOT  BE  CHANGED 

C  2005-B0TH  SB'S  MUST  BE  CLOSED  TO  RECONFIGURE  THE  DATA  STORE 

C  2006-REC0RD  LENGTH  TOO  SHORT 

C 

C--OPTIONS  AVAILABLE 
C 

C  VALUES  OF  iOPT  OPTION  TYPE 

C  . . . 


C 

1 

UNIT  NUMBER  TOR  WORKING  DATA  BASE 

■  l 

c 

2 

UNIT  NUMBER  FOR  REFERENCE  BATA 

I 

c 

3 

UNIT  NUMBER  FOR  DBCS  OUTPUT  FILE 

I 

c 

4 

UNIT  NUMBER  FOR  DBCS  TRACE  FILE 

I 

C 

s 

TRACE  CODE 

I 

c 

4 

ERROR  PRINT  FLAG 

I 

c 

7 

DB  PROTECTION  MODE  FOR  WORKING  DB 

1 

c 

8 

DB  PROTECTION  MOTE  FOR  REFERENCE  DB 

1 

c 

» 

SAF  SMOOTHING  CONSTANT 

R 

c 

10 

LOUER  BOUND  ON  SAF  UPDATE  PERIOD 

I 

c 

11 

UPPER  BOUND  ON  SA?  UPDATE  PERIOD 

I 

c 

12 

(D-NUMBER  OF  PRINT  COLUMNS  OH  THE 

c 

BBCS  OUTPUT  FILE 

I 

c 

C2 » -HUMBER  OF  UNES/PAGE  ON  DBCS 

c 

OUTPUT  FILE 

1 

c 

13 

(t)-NUMBER  OF  PRINT  COLUMNS  ON  THE 

c 

BBCS  TRACE  FILE 

I 

c 

(2J-NUMBER  OF  IINES/PADE  ON  DBCS 

c 

TRACE  FILE 

I 

c 

14 

HUMBER  OF  WORDS  PER  RECORD  OH  DB  FILES 

I 

c 

13 

NUMBER  OF  RECORDS  IN  THE  INTERNAL  STORE 

I 

c 

t6 

NUMBER  OF  RECORDS  IN  THE  NUMERIC 

c 

TEMPORARY  STORE 

I 

c 

17 

NUMBER  OF  RECORDS  IN  THE  CHARACTER 

c 

TEMPORARY  STORE 

I 

c 

C— ALTERNATE  RETURNS} 


C  1-IERR.NE.O 


FUNCTION  DBRNDO 
C— NODULE i  HOPADS/DBCS 
C— REFERENCE:  N0PAD3  VOLUME  5.13 
C— PURPOSE: 

C  73  GENERATE  RANDOM  NUMBERS  FOR  THE  DECS.  THIS  SUBROUTINE  IS 
C  A  SPECIALIZED  VERSION  OF  FUNCTION  BRAND  IN  HSAINT. 

C 

c 

Cm***  ALGORITHM  FOR  SEED  GENERATION  IS  ADAPTED  FROM  FUNCTION  RAND 
C«*«*«  DEVELOPED  BY  L.  SCHRAGE  AND  USED  UITH  THE  AUTHOR'S  PERMISSION. 
C 


SUBROUTINE  D£LDLD<NDB,IDBAA,1DRAA,IERR,») 

C~  MODULE:  NOPADS/DBCS 

C— REFERENCE:  HOPADS  VOLUME  5.13 

C-PURPOSE: 

C  DELDLB  UILL  DELETE  A  DATA  LIST.  IF  WILL  ALSO  KEMCVE 

C  ITS  ENTRY  FROM  THE  DR  THAT  GUNS  IT. 

C~ INPUT  PARAMETERS: 

C  NDI-DATA  BASE(1-UCRKIN6, 2-REFERENCE) 

C—IHPUT/OUTPUT  PARAMETERS: 

C  1DBAA(2)-DBAA  OF  THE  DL.  IT  WILL  BE  ZERO  ON  RETURN 
C  IF  DELETE  IS  SUCCESSFUL. 

C  IDRAA(4)-DRAA  OF  THE  OUN’NS  DIRECTORY, IF  KNQUN.  IF  NOT, 

C  SEND  IDRAAI 1 )*0. 

C— OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  1 2- 1  DBA A  NOT  A  DL 

C  400 B- DL  IDBAA  NOT  IN  CORRECT  DIRECTORY.  D8  FIAUEB 

C  BOOT-INSUFFICIENT  SPACE  IN  KUORKf 

C— ALTERNATE  RETURNS: 

C  t-IERR.NE.O 


SUBROUTINE  OEIDRSCNDB, IDRAA,1DRQAA, IEftR,*> 

C— MODULE:  NOPADS/DBCS 
C— REFERENCE:  HOPADS  VOLUME  5.13 
C— PURPOSE: 

C  DELBRD  UILL  DELETE  A  DIRECTORY.  THE  DR  MUST  BE 

C  EMPTY. 

C 

C — INPUT  PARAMETERS: 

C  NBB-DATA  BASEU-UORKINO, 2-REFERENCE) 

C-’NPUT/OUTPUT  PARAMETERS: 


far 

V 


o  o  n  o  r->  n 


C  II>RAA<4)-TKE  DRAA  OF  THE  OF  TO  BE  DELETED.  ON  RETURN 
C  IT  UILL  BE  ZERO. 

C  IDRQAA(4)-DRAA  OF  THE  OUNING  DIRECTORY  IF  KNQUN.  IF  MU  KNOWN, 

C  SEND  1DRQAA( 1  )=0. 

C--OUTPUT  PARAMETERS: 

C  1ERR-ERROR  CODE 

C  O-NO  ERROR 

C  2001-1DRAA  NOT  EMPTY 

C  15-IDRAA  NOT  A  DR 

C  401 O-IDRAA  NOT  IN  OWNER  DIRECTORY 

C— ALTERNATE  RETURNS: 

C  1-IERR.NE.O 


SUBROUTINE  ERRORD(PROGM,HSS, IERR,KPAR, NKf PAR, NP) 
C— MODULE:  MOPADS/DBCS 
C—REFERENCE:  MOPADS  VOLUME  5.13 
C--PURPOSE: 

C  ERROR  PROCESSING  FOR  THE  DBCS 

C— INPUT  PARAMETERS: 

C  PROGM-CALLING  PROGRAM  NAME(CHARACTER) 

C  MSG-ERROR  MESSAGE (CHAR AC (ER) 

C  IERR-ERROR  CODE 

C  1-19??  INFORMATIVE 

C  2000-299?  WARNING 

C  3000-3999  SEVERE 

C  4000-  FATAL 

C 

C  THE  DBCS  USES  POSITIVE  CODES  ONLY. 

C  THE  USER  MAY  CALL  ERRORD  WITH  NEGATIVE 

C  CODES.  THE  ABSOLUTE  VALUE  OF  THE  CODE  UILL 

C  DETERMINE  ITS  TEVERITY  AS  ABOVE. 

C  KPAR(NK)-INTEGER  ARRAY  TO  BE  PRINTED  UITH 

C  ERROR  MESSAGE  IF  NK.GT.O. 

C  PAR(Nf')-REAL  ARRAY  TO  BE  PRINTED  UITH 

C  ERROR  MESSAGE  IF  NP.GT.O. 

C 


SUBROUTINE  FDBID(NDB , 1D,NID,3DRDL,IDRAA, IDAA, IURK, IERR,*,  ♦) 

— MODULE:  MOPADS/DBCS 
—REFERENCE:  MOPADS  VOt  UME  5.13 
—PURPOSE: 

SEARCH  FOR  AN  ID  OF  A  DL  OR  DR  IN  A  DIRECTORY  AND  RETURN  THE 
D8AA_  THE  DL  OR  DR  POSITION  OF  THE  DIRECTORY  UILL  BE  MOVED 
TO  THE  FG'JND  ID.  IF  IT  IS  NOT  FOUND,  THE  POSITION  IS  NOT 
C  CHAfiSED. 
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C— INPUT  PARAMETERS: 

C  NDB-DATA  BASEU-UCRKING,2-REFERE  ICE) 

C  ID (NID>— ID  TO  SEARCH  *QR 

IDRDL-TYPE  TO  SEARCH 

1 - DR'S 

2- DL'S 

— IHPOT/OUTPUT  PARAMETERS: 

IDRAA(4)"DRAA  OF  THE  DIRECTORY  TO  SEARCH 
—OUTPUT  PARAMETERS: 

IDAA<4)-DBAA  OF  THE  DR  OR  DL  UI.W  ID^DL*. 

IF  IDRDL=2.0NLT  2  WORDS  OF  IDAA  ARE  USED.  IDAA=0 
IF  "ID*  IS  NOT  FOUND. 

IURK(3,NIB)-INTEGER  WORKING  SPACE  FOR  FDB1D 
IERR-ERROR  CODE 
O-NO  ERROR 
—ALTERNATE  RETURNS: 

1- -ID"  NOT  FOUND 

2- IERR.NE.O 


SUBROUTINE  FIDLD(NDB,IDBA,IDLDR,NID,IDRAA, ID,LABEL,IERR,*,+) 
— MODULE:  MOPADS/DBCS 
—REFERENCE:  MOPADS  VOLUME  5.13 
—PURPOSE: 

FIBLD  WILL  RETURN  THE  ID  AND  LABEL  OF  A  DR  OR  DL 
THAT  HAS  A  SPECIFIED  DBA. 

—INPUT  PARAMETERS: 

NDB-DATA  BASEU-UORKING, 2-REFERENCE) 

IDBA(4)-DBAA  OF  THE  DL  OR  DR  TO  FIND 
IDLDR-TYPE  FOR  I  DBA 

1- DR 

2- CL 

NID-LENGTH  OF  ID  ARRAY.  NID  WORDS  OF  THE  IDENTIFIER 
WILL  BE  RETURNED.  I?  NID  IS  GREATER  THAT  NEEDED, 

THE  REMAINDER  WILL  NOT  BE  CHANGED.  IF  NID.Lt.O, 

ONLY  THE  LABEL  WILL  BE  RETURNEDUD  NOT  USED) 

—INPUT/OUTPUT  PARAMETERS: 

IDRAA(4)-DRAA  OF  THE  DIRECTORY  TO  SEARCH  FOR  IDBA.  IT  UILL 
BE  POSITIONED  TO  THE  FOUND  DL  OR  DR.  IF  NOT 
FOUND,  THE  POSITION  UILL  NOT  BE  CHANGED. 

—OUTPUT  PARAMETERS: 

ID(NID)-ARRAY  TO  HOLD  IDENTIFIER  OF  THE  FOUND  DL  OR  DR. 

ZERO  IF  NONE  FOUND.  SEE  NID. 

LABEL-CHARACTER  VARIABLE  TO  HOLD  THE  DL  OR  DR  LADEl. 

DL  LABELS  MAY  HAVE  25  CHARACTERS.  DR  LABELS  MAY  HAVE 
C  40. 
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C  IERR-ERROR  CODE 

C  O-Hfl  ERROR 

C 

C--ALTERNATE  RETURNS: 

C  1—1 DBA  HOT  FOUND 

C  2-IERR.ME.O 

C 


SUBROUTINE  f INDLD(NDB, IDBAA, IERR, *) 

C— NODULE:  MOPADS/DBCS 
C— REFERENCE:  HOPADS  VOLUME  5.1? 

C— PURPOSE: 

C  TO  LOCATE  A  RECORD  OF  THE  DL  OR  DR  IN  THE  DATA 

C  STORE  AND  RETURN  ITS  CURRENT  DBAA  IN  IDBAA. 

C — INPUT  PARAMETERS: 

C  NDP-DATA  BASE  ( 1 -WORKING, 2-REFERNCE) 

C — INPUT/OUTPUT  PARAMETERS: 

C  IDBAA { 2 ) — A  DBAA  OF  A  DL  OR  DR.  1DBAA  UILL  RETURN 

C  UNCHANGED  IF  IDBAA ( 2 )  IS  A  MEMBER  OF  THE 

C  DL  SPECIFIED  IN  IDBAA < 1 ) .  IF  NOT,  A 

C  RECORD  OF  THE  CORRECT  DL  UILL  BE  LOCATEDCOR  READ) 

C  AND  ITS  LOCATION  STORD  IN  IDBAA(2) 

C  -GlfTPUT  PhRAMETERS: 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  .NE.O  ERROR 

C— ALTERNATE  RETURNS: 

C  1-IERR.NE.O 

C 


SUBROUTINE  FHNSFDUTTP) 

C—MODULE:  MOPADS/DBCS 
C— REFERENCE:  MOPADS  VOLUME  5.13 
C — PURPOSE: 

C  FMNSFD  FINDS  THE  MINIMUM  SAF  IN  THF  US  OF 

C  TfPE  ITYP  AND  SETS  THE  VALUES  OF  SAFNND  AND  HNSFD. 

—  INPUT  PARAMETERS: 

ITTP-US  TYPE 

1- NUMERIC 

2- CHARACTER 


'  :  '  1  '  .  / 
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SUBROUTINE  GCD(NDB,IP'.  ,IP2,IR, NDL, IDPAA, CDL, IERR, LAST,*) 

C — NODULE:  MOPADS/DBCS 
C — REFERENCE:  NOPADS  VOLUME  5.13 
C~  PURPOSE: 

C  TO  COPT  DATA  FROM  A  CHARACTER  DL  TO  THE  ARRAY  CDL 
C—INPUT  PARAMETERS! 

C  NDB-DATA  BASEU -WORKING, 2-REFERENCE) 

C  IP1 » IP2— ELEMENTS  IP1  TO  IP2  WILL  BE  COPIED  TO  THE 

C  ARRAY  CDL.  IF  NDL.GT.IP2-IP1+1 ,  THE 

C  REMAINDER  OF  CDL  IS  NOT  DISTURBED.  IF  NDL.LT . 

C  IP2-IP1  +  1 ,  ONLY  NDL  ELEMENTS  URL  BE  COPIED. 

C  SEE  IERR.  IF  IP2.LT.IP1  OR  IP1.LE.O,  RETURN 

C  WITH  NO  ACTION. 

C  1R-FORCE  READ  FLAG 

C  1-DO  NOT  FORCE  READ 

C  2-FORCE  READ  FROM  DISK.  IF  THIS  CAUSES  IN  CORE  DATA 

C  TO  BE  OVERWRITTEN,  IERR=7  ON  RETURN. 

C  NDL-LENGTH  OF  CDL 

C— INPUT/OUTPUT  PARAMETERS! 

C  IDBAA ( 2>-DBAA  OF  THE  DATA  LIST  OR  DIRETORY.  IT  MUST  HAVE 

C  BEEN  OBTAINED  PREVIOUSLY.  6CD  MAY  CHANGE  THE 

C  VALUES  OF  JDBAA  TO  REFLECT  CURRENT  DECS 

C  ADDRESSING.  <1>-D&A,  <2'-DBCSA. 

C— OUTPUT  PARAMETERS! 

C  CDL (NDL) -CHARACTER  ARRAY  TO  HOLD  OUTPUT  VALUES  FROM  THE  D3. 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  4-IDBAA  INVALID 

C  5-1 P 1  AND/OR  IP2  INVALID 

C  6-IP2  EXTENDS  PAST  THE  END  OF  THE  DL  OR  DR 

C  7-FORCE  READ  CAUSES  DATA  TO  BE  OVERWRITTEN. 

C  LAST-LAST  HAS  TWO  MEANINGS 

C  IF  IERR.NE.4,  LAST  IS  THE  LAST  DL  ELEMENT  COPIED 

C  70  THE  OUTPUT  ARRAY. 

C  IF  IERR=6,  LAST  IS  THE  LAST  ELEMENT  OF  THE  DL. 

C  EXISTING  ELEMENTS  BETWEEN  IP1  AND  IP2 

C  FOR  WHICH  THERE  WAS  ROOM  IN  THE  OUTPUT 

C  ARRAY  HAVE  BEEN  COPIED. 

C— ALTERNATE  RETURNS: 

C  1-IERR.NE.O 


SUBROUTINE  bCOLCD(NDB,NCOL, IR1 ,IR2, 1R,NDL, IDBAA,CDl,IERRfLASTC,*) 
C — NODULE:  MOPADS/DBCS 
C— REFEREMHE*  HOPADS  VOLUME  5.13 
C—PURPOSE: 

C  TO  COPT  DATA  FROM  A  COLUMN  OF  A  2-D  DL  TO  THE  CHAR  ARRAY  CDL. 
>-INPUT  PARAMETERS: 

C  NDB-DATA  BASE  U -WORKING ,2-REFERENCE) 

C  NCOL-THE  COLUMN  OF  THE  DL  TO  BE  COPIED 
C  IR1 , IR2-R0U  ELEMENTS  IR1  TO  IR2  OF  COLUMN  NCOL  UILL  BE 
C  COPIED.  IF  NDL.GT. IR2-IR1 +1 ,  THE  REMAINDER  OF  CDL 

C  UILL  NOT  BE  DISTURBED.  IF  NPL-LT.IR2-IR1+1,  ONLY 

C  NDL  ROU  ELEMENTS  UILL  BE  COPIED.  Sit  1£RR.  IF 

C  IR2.LT. IR1  OR  IR1.LE.O,  RETURN  UITH  NO  ACTION 

C  IR-FORCE  READ  FLAG 

C  1-DO  NOT  FORCE  READ 

C  2-FORCE  READ  FROM  DISK.  IF  THIS  CAUSES  IN  CORE  DATA  TO 

C  BE  OVERURITTEN,  IERR=7  ON  RETURN 

C  NDL-lENGTH  OF  CDL 

C  — INPUT/OUTPUT  PARAMETERS: 

C  IDBAA(2)-DBAA  OF  THE  DATA  LIST  OR  DIRECTORY.  IT  MUST  HAVE 

C  BEEN  OBTAINED  PREVIOSLY.  IT  MAY  BE  CHANGED  IN  THIS 

C  SUBROUTINE  TO  REFLECT  CURRENT  DBCS  ADDRESSING. 

C  ( 1 )-DBA, (2)-DBCSA 

C— OUTPUT  PARAMETERS: 

C  CDL (NDL  > -CHAGAu lER  ARRAY  TO  HOLD  OUTPUT  VALUES  FROM  THE  DB. 

C  IERR-EREGrf  CODE 

C  O-NO  ERROR 

C  4-IDBAA  INVALID 

C  5-IR1  AND/OR  IR2  INVALID 

C  6-ATTEMPT  TO  READ  PAST  END  OF  THE  DATA  LIST. 

C  SEE  LA3TC. 

C  7-FORCE  READ  FLAG  CAUSES  DATA  TO  BE  0VERURIT7 

C  9-ATTEMPT  TO  USE  INCORRECT  DIMENSIONS  TO  ACCESS  DB 

C  1 0-IilL  NOT  CHARACTER 

C  LASTC-IF jlERR.NE.6,  LASTC=0 

C  IF  I ERR=6 ,  LASTC=7HE  LAST  DEFINED  COLUMN  OR  ROU 

C  i  IN  THE  DL. 


C— ALTERNATE  RETURNS: 
C  1-IERR.NE.O 

C 


SUBROUTINE  GCOLID(KDB,NCOL, IR1 , IR2,IR,NDL, IDBAA, IDL , IERR.LASTC, *) 
C — MODULE:  MOPADS/DBCS 
C— REFERENCE:  MOPADS  VOLUME  5.13 
C—PURPOSE: 
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C  TO  COPY  DATA  FROM  A  COLUMN  OF  A  2-D  DL  TO  THE  INTEGER  ARRAY  IDL. 
C — INPUT  PARAMETERS: 

C  NOB-DATA  BASE  <1-U0KKIN0#2-REFFRENCE! 

C  NCOL-THE  COLUMN  OF  THE  DL  TO  BF  CO°IED 
C  1R1.IR2-R0U  ELEMENTS  IRT  TO  IR2  OF  COLUMN  NCOL  UILL  BE 
C  COPIED.  IF  NDL.CT.IR2-IRI+1,  THE  REMAINDER  OF  IDL 

C  UILL  HOT  BE  PISTUF1DE!..  IF  NDL.LT.IR2-IR1+1 ,  ONLY 

C  NDL  ROU  ELEMENTS  E* ILL  BE  COPIED.  SEE  1ERR.  IF 

C  IR2.LT. IR1  OR  IR1.LE.O,  RETURN  U1TH  NO  ACTION 

C  IR-FORCE  READ  FLAG 

C  1-DO  NOT  FORCE  READ 

C  2-FORCE  READ  FROM  DISK.  IF  THIS  CAUSES  IN  CORE  DATA  TO 

C  BE  OVERWRITTEN,  IERR=7  ON  RETURN 

C  NDL-LENGTH  OF  IDL 

C-- INPUT/OUTPUT  PARAMETERS: 

C  IDBAA(2)-DBAA  OF  THE  DATA  LIST  OR  DIRECTORY.  IT  MUST  HAVE 
C  BEEN  OBTAINED  PREVIOSLY.  IT  HAY  BE  CHANGED  IN  THIS 

C  SUBROUTINE  TO  REFLECT  CURRENT  DBCS  ADDRESSING. 

C  ( 1 )-DBA, (2)-DBCSA 

C — OUTPUT  PARAMETERS: 

C  IDL(NDL)-INTEGER  ARRAY  TO  HOLD  OUTPUT  VALUES  FROM  THE  DB. 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  4-IB8AA  INVALID 

C  5-IR1  AND/OR  IR2  INVALID 

C  6-ATTEHPT  TO  READ  PAST  END  OF  THE  DATA  LIST. 

C  SEE  LASTC. 

C  7-FORCE  READ  FLAG  CAUSES  DATA  TO  BE  OVERWRITTEN. 

C  9-ATTEMPT  TO  USE  INCORRECT  DIMENSIONS  TO  ACCESS  DB 

C  lO-DL  NOT  INTEGER 

C  LASTC-IF  IERR.NE.6,  LASTC=0 

C  IF  IERR=6,  LASTC=THE  LAST  DEFINED  COLUMN  OR  ROU 

C  IN  THE  DL. 

C— ALTERNATE  RETURNS: 

C  1-1  ERR . NE . 0 

C 


SUBROUTINE  GLOLRD<  NDB,NCQL, IR1 , IR2, IR.NOL, IDBAA,RDL , IERR.LASTC, * ) 
C— MODULE:  MOPADS/DBCS 
C — REFERENCE:  MOPADS  VOLUME  5.13 
C— PURPOSE 

C  TO  COPY  DATA  FROM  A  COLUMN  OF  A  2-D  DL  TO  THE  REAL  ARRAY  ROL. 

C — INPUT  PARAMETERS: 

C  NDS-DATA  BASE  (1-UORK I  NT  ,2-REFERENCE) 

C  NCC'L-THE  COLUMN  OF  THE  DL  TO  BE  COPIED 
C  IR1 , IR2-ROU  ELEMENTS  IR1  TO  IR2  OF  COLUMN  .TCOL  UI„L  BE 
C  COPIED.  IF  NDL.GT.IR2IK1-1,  THE  REMAINDER  OF  RDL 
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C  U ILL  MOT  BE  DISTURBED.  IF  HDL.LT.IR2-1R1+1 ,  .NLY 

C  HDL  60-  ELEMENTS  WILL  BE  COPIES.  SEE  IERS.  IF 

C  IR2.LT. IR1  OR  IR1.LE.0,  RETURN  WITH  NO  ACTION 

C  IR-FORCE  READ  FLAG 
C  1-D0  NOT  FORCE  READ 

C  2-FORCE  READ  FROM  DISK.  IF  THIS  CAUSES  IN  CORE  DATA  TO 

C  BE  OVERWRITTEN,  1ERR*7  ON  RETURN 

C  NDL-LENGTH  OF  RDL 

C--INPUT/OUTPUT  PARAMETERS: 

C  IDBAA(2)-DBAA  OF  THE  DATA  LIST  OR  DIRECTORY.  IT  MUST  HAVE 
C  BEEN  OBTAINED  PREVIOSLY.  IT  MAT  BE  CHANGED  IN  THIS 

C  SUBROUTINE  TO  REFLECT  CURRENT  DBCS  ADDRESSING. 

C  (1 )-DBA, (2J-DBC3A 

C— OUTPUT  PARAMETERS: 

C  RDL(NDL)-REAL  ARRAY  TO  HOLD  OUTPUT  VALUES  FROM  THE  DB. 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  4-IDBAA  INVALID 

C  5-IR1  AND/OR  IR2  INVALID 

C  6-ATTEMPT  TO  READ  PAST  END  OF  THE  DATA  LIST. 

C  7-FORCE  READ  FLAG  CAUSES  DATA  TO  BE  OVERWRITTEN. 

C  9-ATTEMPT  TO  USE  INCORRECT  DIMENSIONS  TO  ACCESS  DB 

C  10-DL  NOT  REAL 

C  LASTC-IF  1ESR.NE.6,  LASTC=0 

C  IF  IERR=6,  LASTC=THE  LAST  DEFINED  COLUMN  OR  ROW 

C  IN  THE  DL. 

C— ALTERNATE  RETURNS: 

C  1-IERR.HE.O 

C 


SUBROUTINE  GDLLBBINDB, LABEL, IDRAA,IDBAA,IERR,»,*> 

C — M  -5ULE :  MOPADS/DBCS 
C— REFERENCE:  MOPADS  VOLUME  3.13 
C — PURPOSE: 

C  GDLLBD  WILL  FIND  THE  DBAA  OF  A  DL  THAT  HAS  A  SPECIFIED  LABEL  IN 

C  A  DIRECTORY. 

C— INPUT  PARAMETERS: 

C  NDB-DATA  BASE< 1 -WORKING, 2-REFERENCE > 

C  LABEL-(CHARACTER)  LABEL  OF  THE  DL.  IT  MUST  EXACTLY  MATCH  AN 
C  EXISTING  DL  LABEL  IN  THE  DIRECTORY. 

C  —  INPUT/OUTPUT  PARAMETERS: 

C  IBRAAM)-;h£  DIRECTORY  TO  SEARCH  FOR  A  DL  UITH  LABEL*  'LABEL 
C  IF  FOUND,  THE  DL  WILL  BECOME  THE  CURRENT  POSITION 

C  IN  THE  DIRECTORY. 

C — OUTPUT  PARAMETERS: 

C  1BBAA(2)-DBAA  OF  THE  FOUND  DL.  ZERO  IF  NCf  FOUND. 

C  IERR-ERROR  CODE 
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C  O-NO  ERROR 

c 

£ _ ALTERNATE  RETURNS: 

C  1-NO  DL  WITH  THE  SPECIFIED  LABEL  UAS  FOUND.  CJRRENT  POSITION 
C  OF  IDRAA  IS  NOT  CHANGED. 

C  2-IERR.NE.O 


SUBROUTINE  GDRLBIHNDB, LABEL,  IDRAA,IERR, *,*) 

C — NODULE:  MOPADS/DBC3 
C— REFERENCE:  NOPADS  VOLUNE  S.13 
C— PURPOSE: 

C  GDRLBD  UIlL  FIND  THE  DRAA  OF  A  DR  GIVEN  ITS  LABEL. 

C  IF  NON-UNIQUE  DIRECTORY  LABELS  EXIST,  GDRLBD  UILL 
C  RETURN  THE  FIRST  DIRECTORY  IT  ENCOUNTERS  UITK  THE 
C  SPECIFIED  LABEL. 

C 

C— INPUT  PARAMETERS: 

C  NDB-DATA  BASEI1-UORKING, 2-REFERENCE) 

C  LABEL— (CHARACTER)  LABEL  OF  THE  DR  TO  SEARCH  FOR.  IT 

C  HUST  EXACTLY  HATCH  AN  EXISTING  DR  LABEL. 

C— OUTPUT  PARAMETERS: 

C  IDRAA(4)-A  DRAA  FOR  THE  FOUND  DR.  ZERO  IF  NONE  FOUND. 

*  C  1ERR-ERROR  CODE 

C  O-NO  ERROR 

C— ALTERNATE  RETURNS: 

C  1 -'LABEL'  NOT  FOUND 

C  2-IERR.NE.O 


SUBROUTINE  GETRCDI NDB, IDBAA, IPT, IERR,+) 

C— MODULE:  MOPADS/DBCS 
C — REFERENCE:  MOPADS  VOLUME  5.13 
C— PURPOSE: 

C  GETRCD  READS  RECORDS  INTO  THE  TS  AND/OR  THE  US. 

C  IT  HANAGES  THE  STORAGE  SPACE  AND  UPDATES  SAF'S 

C  IF  NEEDED.  ON  RETURN,  THE  RECORD  IS  NOT  LINKED 

C  INTO  THE  DATA  STORE. 

C— INPUT  PARAMETERS: 

C  NDB-DATA  BASE  ( 1-UORKING, 2-REFERENCE ) 

C— INPUT/OUTPUT  PARAMETERS: 

C  IDBAA ( 2 ) -  m-(INPUT)  DBA  OF  THE  REC0RD1.LT.0  IF 

C  CHARACTER) 

C  ( 2 >  —  < OUTPUT )  THE  DBCSA  OF  THE  RECORD 

C— OUTPUT  PARAMETERS: 

C  IPY-LOCATIQN  FROM  LS TOR D .  IPT  UILL  *2, 3, 6, OR  7 

C  IERR-ERROR  CODE 


C  t  HO  ERROR 

C  3004,4002 

C 

C--ALTERNATI  RETURNS* 

C  1-IERR.NE.O 

C 


SUBROUT  I  ME  6ID(NDB,IP1,IP2,IR,NDL,IBBAA, IDL, IERR, LAST,*) 
C--HOBULE*  MOPADS/DICS 
C— REFERENCE:  HOPABS  VOLUflE  5.13 
C--PURPOSE* 

C  TO  COPT  DATA  FROM  AN  INTEGER  DL  OR  DR  TO  THE  ARRAY  1DI 
C— INPUT  PARAMETERS: 

C  NBB-BATA  BASEd-WORKING, 2-REFERENCE) 

C  IP1,IP2-ELE«ENTS  IP!  TO  IP2  U ILL  BE  COPIED  TO  THE 
C  ARRAY  IDl.  IF  NBL.6T.IP2-IP1+1 ,  THE 

C  RENAINDER  OF  IDL  IS  NO’  DISTURBED*  IF  NDL.LT. 

C  IP2-IP1+1,  ONLY  NDL  ELEMENTS  UILL  BE  COPIED. 

C  SEE  IERR.  IF  IP2.LT.IP1  OR  IP1.LE.0,  RETURN 

C  UITN  NO  ACTION. 

C  IR-FORCE  READ  FLAS 

C  1-DO  NOT  FORCE  READ 

C  2-FORCE  READ  FROM  DISK.  IF  THIS  CAUSES  IN  CORE  DATA 

C  YO  BE  OVERWRITTEN,  IERR-7  ON  RETURN. 

C  NDL-LEN3TH  OF  IBL 

C  — INPUT/OUTPUT  PARAMETERS: 

C  IDBAA(2)-D6AA  OF  THE  DATA  LIST  0*  DIRETORY.  IT  HUST  HAVE 

C  BEEN  OBTAINED  PREVIOUSLY.  6ID  NAY  CHANGE  THE 

C  VALUES  OF  IDBAA  TO  REFLECT  CURRENT  DECS 

C  ADDRESSING.  d)-BBA,  <2>-BBCSA. 

C— OUTPUT  PARAMETERS: 

C  1DL<HDL)-IHTEG£R  ARRAY  TO  HOLD  OUTPUT  VALUES  FROM  THE  DB. 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  4-IDBAA  INVALID 

C  5-IP1  AND/OR  IP2  INVALID 

C  A-IP2  EXTENDS  PAST  THE  END  OF  THE  DL  OR  DR 

C  7-FORCE  READ  CAUSES  DATA  TO  BE  UVEKUR1TTEN. 

C  LAST-LAST  HAS  TUO  MEANINGS 

C  IF  IERR.NE.6,  LAST  IS  THE  LAST  DL  ELEMENT  COPIED 

C  TO  THE  OUTPUT  ARRAY. 

C  IF  IERR*4,  LAST  IS  THE  LAST  ELEMENT  OF  THE  DL. 

C  EXISTING  ELEMENTS  BETWEEN  IP1  AND  IP2 

C  FOR  WHICH  THERE  WAS  ROOM  IN  THE  OUTPUT 

C  ARRAY  HAVE  BEEN  COPIED. 

C — ALTERNATE  RETURNS: 

C  1 -IERR. HE. 0 
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SUBROUTINE  6LBBLB<ND8,IBBAA, LABEL, IERR,*) 
C — HOOULEt  HOPADS/DBCS 
C--REFERENCE:  HOPABS  VCLUHE  5.13 
C— PURPOSE: 

C  TO  RETRIEVE  A  LABEL  TO  A  BL. 

C 

C— 'INPUT  PARAHETERS: 

C  NDB-BATA  BASEL 1-UORK1NG, 2-REFERENCE) 

C  IBBAA(2)-BBAA  OF  A  RECORD  OF  THE  DL. 

C-OUTPUT  PARAHETERS: 

C  LABEL-BL  LABEL(CHARACTER). 

C  IERR-ERROR  COBE 

C  O-NO  ERROR 

C  12-1 DB AA  NOT  A  BL., 

C  1 3— DL  HAS  NO  LABEL 

C— ALTERNATE  RETURNS: 

C  1-IERR.NE.O 


SUBROUTINE  GLBDRDLNBB, IDP'.A,LABEL,lERRt*,*> 
C--HODULE:  HOPAOS/DBCS 
C— REFERENCE:  HOPABS  VOLUHE  5.13 
C— PURPOSE: 

C  GLBBRB  WILL  FINB  THE  LABEL  OF  A  BR  GIVEN  ITS  DBA 
C— INPUT  PARAHETERS: 

C  NDB-BATA  BASEL1-UORKING, 2-REFERENCE) 

C— INPUT/OUTPUT  PARAHETERS: 

C  IDRAA(4)-DRAA  OF  THE  DIRECTORY 

C— OUTPUT  PARAHETERS: 

C  LABEL-CHARACTER  VARIABLE  FOR  THE  DK  LABELLUP  TO  40 
C  CHARACTERS) 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C 

C — ALTERNATE  RETURNS:  , 

C  1-IDRAA  NOT  FOUND  | 

C  2-IERR.NE.O 


SUBROUTINE  GLBELDLNDB, IRC, IL1 ,IL2,NLBL, IDBAA, LABEL, IG1,IG2, 
IERR,*) 

C — HOBULE:  HOPADS/BBCS 
C— REFERENCE:  HOPABS  VOLUHE  5.13 
C— PURPOSE: 


C  6LBELB  RETRIEVES  LABELS  PF  DL  ELEMENTS. 
C— INPUT  PARAMETERS: 


C 

C 

C 

C 

c 

c 

c 

c 

c 

c 

c 

c 

c 


MSB-DA7A  BftSE<1-W0RKING, 2-REFERENCE) 
IRC-RQU/COLUMil  INDICATOR 
IRC.GT.O-HOW  IRC 
IRC.LT.O-COLUHN  (-IRC) 


IRC«0  1-9  BATA  LIST 
1L1  ,IL2-ELEIt  IT  NUHSERS 

IRC.  T. O-THESE  ARE  THE  FIRST  AND  LAST  COLUMNS 

OF  ROU  IRC  WHOSE  LABELS  ARE  TO  BE  SOTTEN. 
IRC.lT .O-THESE  ARE  THE  FIRST  AND  LAST  ROUS  OF  COLUMN 
-IRC  WHOSE  LABELS  ARE  TO  BE  GOTTEN. 

IRC. EQ. O-THESE  ARE  THE  FIRST  AND  LAST  ELEMENT**  WHOSE 
LABELS  ARE  TO  BE  SOTTEN. 

NLBI.-LENGTH  OF  OUTPUT  ARRAY  (LABEL) 

C— INPUT/OUTPUT  PARAMETERS: 

C  IDBAA(2)-DBAA  OF  THE  DL  WHOSE  ELEMENTS  LABELS  ARE  TO  BE  SET. 
C— OUTPUT  PARAMETERS: 

C  LABEL (NLBL /-CHARACTER  ARRAY  FOR  LABELS. 

C  IF  IL2-1L1+1 .GT.NLIL,  ONLY  NLBL  LABELS  UILI 

C  be  c:;abged. 

C  IF  IL2-IL1+1.LT.NLBL,  ONLY  IL2-IL1+1  ELEMENTS  OF 

C  LABEL  WILL  BE  REFERENCED. 

C  161 ,IG2-ACTUAL  ELEMENTS  COPIED  TO  LABEL. 

C  IS1  AND  IG2  CORRESPOND  IN  MEANING  TO  IL1  AND  IL2. 

C  IF  IERR.EQ.O,  IG1*!L1,  IG2*MIN(IG1+NLBL-1,IL2> 

C  IF  lERR.EQ.A,  1S1  AND  IG2  EQUAL  ACTUAL  ELEMENT 

C  LABELS  COPIED.  IF  NONE,  161*102=0. 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  5,4,9,12 

C— ALTERNATE  RETURNS: 

C  1-1ERR.NE.Q 

C 


SUBROUTINE  GRD< NDB . IP! , IP2, IR.NDL, IDBAA,RDL , 1ERR.LAST ,* ) 
C— MODULE:  MOPADS/DBCS 
C— REFERENCE:  MOPAOS  VOLUME  5.J3 
C— PURPOSE: 

C  TO  COPY  DATA  FROM  X  REAL  DL  TO  THE  ARRAY  RDL 
C— INPUT  PARAMETERS: 

C  NDB-DATA  BASE ( 1 -WORKING, 2-REFERENCE) 

C  IP1 , IP2-ELEMENTS  IP1  TO  IP2  WILL  BE  COPIED  TO  THE 
C  ARRAT  RDL.  IF  NDL.GT. IF2-IP1 +1 ,  THE 

C  REMAINDER  OF  RDL  IS  NOT  DISTURBED.  IF  NDL.LT. 

C  IP2-IP1+1,  ONLY  NDL  ELEMENTS  WILL  BE  COPIED. 

C  SEE  IERR.  IF  IP2.LT.IP1  OR  IP1.LE.0,  RETURN 
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C  WITH  NO  ACTION, 

C  IR-FORCE  READ  FLAB 
C  1-DO  NOT  FORCE  BEAD 

C  2-FORCE  READ  FROK  DISK.  IF  THIS  CAUSES  IN  CORE  DATA 

C  TO  BE  OVERURITTEN,  I£RR«7  ON  RETURN. 

C  NDL-LENGTH  OF  RDL 

:—INPUr/OUTPUT  FARAMETERS* 

C  IDBAA(2)-DBAA  OF  THE  DATA  LIST  OR  DIRETORY.  IT  MUST  HAVE 
C  BEEN  OBTAINED  PREVIOUSLY.  6RD  HAY  CHANGE  THE 

C  VALUES  Dr  1DBAA  TO  REFLECT  CURRENT  DBCS 

C  ADDRESSIN6.  <1)-DBA,  (21-BICSA. 

C — OUTPUT  PARAMETERS* 

C  RDL(NDL)-REAL  ARRAY  TO  HOLD  OUTPUT  VALUES  FROM  THE  BB. 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  4-IDBAA  INVALID 

C  5-IP1  AND/OR  IP2  INVALID 

C  A-1P2  EXTENDS  PAST  THE  END  OF  THE  DL  OR  DR 

C  7-FORCE  READ  CAUSES  DATA  TO  BE  OVERURITTEN. 

C  LAST-LAST  HAS  TUO  MEANINGS 

C  IF  IERR.NE.6,  LAST  IS  THE  LAST  DL  ELEMENT  COPIED 

C  TO  THE  OUTPUT  ARRAY. 

C  IF  IERRZ6,  LAST  IS  THE  LAST  ELEMENT  OF  THE  DL. 

C  EXISTING  ELEMENTS  BETWEEN  IPt  AND  IP2 

C  FOR  WHICH  THERE  UAS  ROOM  IN  THE  OUTPUT 

C  ARRAY  HAVE  BEEN  COPIED. 

C— ALTERNATE  RETURNS* 

C  1-IERR.NE.O 

C 


SUBROUTINE  GR0UCD(NDB,NR0U, IC1 ,IC2, IR,NDl,IDBAA,CDL,lERR,LASTR,-») 
C — MODULE*  MOPADS/DBCS 
C — REFERENCE^!  MOPAD5  VOLUME  5.13 
C— PURPOSE* 

C  TO  COPY  DATA  FROM  A  ROU  OF  A  2-D  DL  TO  THE  CHAR  ARRAY  CDL. 

C — INPUT  PARAMETERS* 

C  NDB-DATA  BASE  ( 1 -WORKING, 2-REFERENCE) 

C  NROU-T.'4E  ROU  OF  THE  DL  TO  BE  COPIED 
C  IC1 ,IC2-COLUMN  ELEMENTS  IC1  TO  IC2  0*  ROU  NROU  UILL  BE 
C  COPIED.  IF  NDL.GT.IC2-IC1+1 ,  THE  REMAINDER  OF  CDL 

C  UILL  NOT  BE  DISTURBED.  IF  NDL.LT.IC2-IC1+1,  ONLY 

C  NDL  COLUMN  ELEMENTS  UILL  BE  COPIED.  SEE  IERR.  IF 

C  IC2.LT. ic;  OR  ICT.LE.O,  RETURN  UITH  NO  ACTION 

C  IR-FORCE  READ  FLAG 

C  1-DO  NOT  FORCE  READ 

C  2-FORCE  READ  FROM  DISK.  IF  THIS  CAUSES  IN  CORE  DATA  TO 

C  BE  OVERURITTEN,  IERR*7  ON  RETURN 
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C  NDL-LENGTK  OF  COL 
C~~1NPUT /OUTPUT  PARAMETERS: 

C  IDBAA<2)-DBAA  OF  THE  UATA  LIST  OR  DIRECTORY.  IT  MUST  HAVE 
C  HEN  OBTAINED  PREVIGSLY.  IT  MAY  BE  CHANGED  IN  THIS 

C  SUBROUTINE  TO  REFLECT  CURRENT  DBCS  ADDRESSING. 

C  <n-BBA,(2>-DBCCA 

C— OUTPUT  PARAMETERS: 

C  CDL(NDL) -CHARACTER  ARRAY  TO  HOLD  OUTPUT  VALUES  FROM  THE  DB. 

C  IERR-ERRQR  CODE 

C  O-NO  ERROR 

C  4-IDBAA  INVALID 

C  5-IC1  AND/OR  IC2  INVALID 

C  6-ATTEMPT  TO  READ  PAST  END  OF  THE  DATA  LIST. 

C  7-FORCE  READ  FLAG  CAUSES  DATA  TO  JE  OVERWRITTEN. 

C  9-ATTEMPT  TO  USE  INCORRECT  DIMENSIONS  TO  ACCESS  DB 

C  10-DL  NOT  CHARACTER 

C  LASTR-IF  IERR.NE.6,  LASTR=0 

C  IF  1ERR*6,  LASTR*THE  LAST  DEFINED  ROU  OR  COLUMN 

C  IN  THE  DL. 

C— ALTERNATE  RETURNS: 

C  t-lERR.NE.O 

C 


SUBROUTINE  GROUID<NDB,NROUf 1C1 ,IC2,IR.MDL,IDBAA,tDL,IERR,LASTR,*) 
C — MODULE:  M0PADS/D6CS 
C— REFERENCE:  MOPADS  VOLUME  3.J3 
C— PURPOSE: 

C  TO  COPY  DATA  FROM  A  ROU  OF  A  2-D  DL  TO  THE  INTEGER  ARRAY  IDL. 

C— INPUT  PARAMETERS: 

C  NDB-DATA  BASE  ( 1-UORK I NG,  2 -REFERENCE) 

C  NROU-THE  ROU  OF  THE  DL  TO  BE  COPIED 
C  ICt ,IC2-C0LUHN  ELEMENTS  IC1  TO  IC2  OF  ROU  NROU  UILL  BE 

C  COPIED.  IF  NDL.GT.IC2-IC1+1,  THE  REMAINDER  OF  IDL 

C  UILL  NOT  BE  DISTURBED.  IF  NDL.LT.IC2-IU-M ,  ONLY 

C  NDL  COLUMN  ELEMENTS  UILL  BE  COPIED.  SEE  IERR.  IF 

C  IC2.LT.IC1  OR  IC1.LE.O,  RETURN  UITH  NO  ACTION 

C  IR-FURCE  READ  FLAG 

C  1-DO  NOT  FORCE  READ 

C  2-FORCE  READ  FROM  DISK.  IF  THIS  CAUSES  IN  CORE  DATA  TO 

C  BE  OVERWRITTEN,  IERR-7  ON  RETURN 

C  NDL-LENGTH  OF  IDL 

C— INPUT/OUTPUT  PARAMETERS: 

C  IDBAA(2)-DBAA  OF  THE  DATA  LIST  OR  DIRECTORY.  IT  MUST  HAVE 

C  BEEN  OBTAINED  PREVIOSLY.  IT  MAY  BE  CHANGED  IN  THIS 

C  SUBROUTINE  TO  REFLECT  CURRENT  DBCS  ADDRESSING. 

C  <U-D8A,(2)-DBCSA 

C— OUTPUT  PARAMETERS: 
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IDL(f!DL)-INTESER  ARRAY  TO  HOLD  OUTPUT  VALUES  FRCU  THE  DB. 

ierk-er.:or  code 

0-NO  ERROR 

4- IDBAA  INVALID 

5- IC1  AND/OR  IC2  INVALID 

A-ATTEMPT  TO  READ  PAST  END  OF  THE  DATA  LIST. 

7-FORCE  READ  FLAG  CAUSES  DATA  TO  BE  OVERWRITTEN. 
0-ATTEMPT  TO  USE  INCORRECT  DIMENSIONS  TO  ACCESS  DB 
tO-DL  NOT  INTE6ER 
LASTR-IF  IERR.NE.6,  LASTR*0 

IF  IERR»A,  LASTR-THE  LAST  DEFINED  ROU  OR  COLUMN 
IN  THE  DL. 

-ALTERNATE  RETURNS; 

1-IERR.NE.O 


SUBROUTINE  &ROURD<NDB,NROU,!Cf tlC2,IRf NDL,IBBAA,RDL,IERR,LASTRf*> 
—NODULE:  HOPADS/DBCS 
—REFERENCE:  HUPADS  VOLUME  5.13 
—PURPOSE: 

TO  COPY  DATA  FRON  A  ROU  OF  A  2-D  DL  TO  THE  REAL  ARRAY  RDL. 

— INPUT  PARAMETERS: 

HDB-DATA  BASE  < 1 -UORKING, 2-REFERENCE ) 

NROU-THE  ROU  OF  THE  DL  TO  BE  COPIED 

ICt , I C2-C0LUMN  ELEMENTS  IC1  TO  IC2  OF  ROU  NROU  UILL  BE 

COPIED.  IF  NBL.GT.IC2-IC1+1 ,  THE  REMAINDER  OF  RDL 
C  UILL  NOT  BE  DISTURBED.  IF  NDL.LT,IC2-IC1*1 ,  ONLY 

C  NDL  COLUMN  ELEMENTS  UILL  BE  COPIED.  SEE  IERR.  IF 

C  IC2.LT. IC1  OR  ICt .LE.O,  REHIRN  WITH  NO  ACTION 

C  IR-FORCE  READ  FLAG 

C  1-DO  NOT  FORCE  READ 

C  2-FORCE  READ  FROM  DISK.  IF  THIS  CAUSES  IN  CORE  DATA  TO 

C  BE  OVERWRITTEN,  IERR=7  UN  RETURN 

C  NDL-LEMGTH  OF  RDL 

C— INPUT/OUTPUT  PARAMETERS: 

C  X DBAA ( 2> -DBAA  OF  THE  DATA  LIST  OR  DIRECTORY.  IT  MUST  HAVE 

C  BEEN  OBTAINED  PREVIOSLY.  IT  MAT  BE  CHANGED  IN  THIS 

C  SUBROUTINE  TO  REFLECT  CURRENT  DBCS  ADDRESSING. 

C  ( 1 )-DBA, (2)-DBCSA 

C— OUTPUT  PARAMETERS: 

C  RDL(NDL)-REAL  ARRAY  TO  HOLD  OUTPUT  VALUES  FR2M  THE  DB. 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  4-IDBAA  INVALID 

C  5-IC1  AND/OR  IC2  INVALID 

C  6-ATTEHPT  TO  READ  PAST  END  OF  THE  DATA  LIST. 

C  7-FORCE  READ  FLAG  CAUSES  DATA  10  BE  OVERURITTEN. 


C  9-ATTEMPT  TO  USE  INCORRECT  DIMENSIONS  TO  ACCESS  DB 

C  10-DL  NOT  REAL 

C  LASTR-IF  IERR.NE.6,  LASTRO 

C  IF  IERRS6;  LASTR»THE  LAST  DEFINED  RQU  OR  COLUMN 

C  IN  THE  PL. 

C— ALTERNATE  RETURNS t 
C  1-4ERR.NE.0 

C 


SUBROUTINE  GSAFD<IDBAA,SAF,IERRf *) 

C— MODULE:  MQPADS/BBCS 
C— REFERE’iCt ;  HOPADS  VOLUME  5.13 
C— PURPUSE: 

C  TO  RETRIEVE  THE  SAF  OF  A  DL  OR  DR  RECORD. 

C — INPUT  PARAMETERS* 

f  IDBAA(2)-CURRENT  BBAA  OF  THE  DL  OR  DR  RECORD.  AN 
C  ERROR  RESULTS  IF  IDUAA  IS  NOT  CURRENT. 

C— OUTPUT  PARAMETERS; 

C  SAF-VALUE  OF  THE  SAF  FOR  THE  RECORD  AT  IDBAA. 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  1 1 -IDBAA  SET  CURRENT  VALUE  OF  SAF  NOT  CHANGED) 

C— ALTERNATE  RETURNS; 

C  1-IESR.NE.O 


SUBROUTINE  INCPDtNP, NR.NS, IDBA,IENTYfKCP) 

C— MODULE;  MOPADS/DBCS 
C— REFERENCE;  MOPADS  VOLUME  5.13 
C — PURPOSE; 

C  TO  INITIALIZE  A  CONTROL  PART.  SOME  OF  THE 

C  ELEMENTS  OF  THE  CONTROL  PART  ARE  PASSED 

C  TO  INCPD.  OTHER  ELEMENTS  ARE  SET  TO  ZERO. 

C — INPUT  PARAMETERS; 

C  NP-PREDECESSOR  RECORD 

C  NR-THE  RECORD  NUMBER 

C  NS-THE  SUCCESSOR  RECORD 

C  IDBA-INITIAl  DATA  BASE  ADDRESS  OF  THIS  DL  OR  DIRECTORY 

C  IENTY-ENTITT  TYPE ( 1 -DIRECTORY, 2-1 DL,3-RDLr4-CDL,5-LDL) 

C— OUTPUT  PARAMETERS; 

C  KCP(NUCPD)-ARRAT  TO  HOLD  THE  CONTROL  PART. 
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SUBROUTINE  IN TTD ( IERR , * ) 

C--HODULE:  MOPADS/DBCS 
C — REFERENCE:  NOPADS  "OLUNE  5.13 
C— PURPOSE: 

C  IKITD  UILL  SET  UP  THE  DBCS  DEFAULT  CONDITION.  IT  KUST  BE 
C  CABLED  ONCE  PRIOR  TO  CALLING  ANY  OTHER  DBCS  PROGRAMS. 

C  IT  HAY  PE  CALLED  AT  ANY  TIME  TO  RESTORE  THE  DEFAULT  SET-UP. 

C  INITD  UILL  CLOSE  ANY  DB"S  THAT  ARE  OPEN. 

C 

C  INITD  DOES  NOT  RESTORE  THE  DEFAULTS  FOR  THE  FOLLQUING 
C  VARIABLES: 

C  LUD  ITRCD 

C  NISD  KEPFD 

C  JOUTD  KF'RTD 

C  JTRCD 

C 

C — OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  4001 -INSUFFICIENT  DATA  STORE  SPACE 

C 

C — ALTERNATE  RETURNS: 

C  1 -IERR.NE.0 


SUBROUTINE  INPD(PROGM) 

C — MODULE :  MOPADS/DBCS 
C— REFERENCE:  MOPADS  VOLUME  5.13 
C — PURPOSE: 

C  INPD  INCREMENTS  THE  DBCS  SUBROSRAM  LEVEL  AND 

C  PRINTS  THE  ENTERING  TRACE  MESSAGE  UHEN  A 

C  PROGRAM  IS  CALLED  AND  TRACING  IS  ON. 

C— INPUT  PARAMETERS: 

C  PROGM-NAME  OF  THE  "CALLING  SUBPROGRAM (CHARACTER) 

C 


ENTRY  OUTPD 

C — MODULE:  MOPADS/DBCS 
C— REFERENCE:  MOPADS  VOLUME  5.13 
C  —  PURPOSE: 

C  OUTPD  DECREMENTS  THE  DBCS  SUBPROGRAM  LEVEL  FOR 

C  DBCS  TRACING.  OUTPD  IS  IN  SUBROUTINE  INPD. 

C 
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SUBROUTINE  INSDRD1NDB , IDRDL,IDBRA, IDfNIT1, IDTO.ISRR,*) 

C — MODULE*  MOPADS/DBCS 
C— REFERENCE:  NOPADS  VOLUME  5,13 
C — PURPOSE: 

C  1NSDRD  WILL  INSERT  A  DL  OR  DR  INTO  ITS  CORRECT  POSITION 
C  IN  A  DR.  THE  INSERTED  ENTITY  BECONES  THE  CURRENT  POSITION. 
C— INPUT  PARAMETERS: 

C  NDB-DATA  BASEl 1 -WORKING, 2-REFERENCE) 

C  IDRDL-TYPE  TO  BE  INSERTED 

C  1-DR 

C  2-DL 

C  IDBRA(4)-DRAAnDRDL=1)  OF  DBAAUDRDL*2)  OF  THE  ENTITY  TO  BE 
C  INSERTED  INTO  THE  DR. 

C  1 0 ( N I D ) - t HE  IDENTIFIER  OF  IDBRA 

C — INPUT/OUTPUT  PARAMETERS: 

C  IDBO(4>-DRAA  OF  THE  DR  THAT  UILL  OUN  IDBRA. 

C  U.t.  THE  DR  TO  INSERT  IDBRA  INTO.) 

C— OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  15-IDBO  NOT  A  DIRECTORY 

C  2002-IDBRA  HOT  OF  TYPE  IDRDL 

C— ALTERNATE  RETURNS: 

C  1-IERR.NE.O 


SUBROUTINE  KPNPD(KPN,LENN, IOFF) 

C — MODULE:  MOPADS/DBCS 
C— REFERENCE:  MOPADS  VOLUME  5.13 
C— PURPOSE: 

C  GIVEN  A  PARTITION  OF  THE  DATA  STORE(KPN) ,KPNPD 
C  RETURNS (7HE  LENGTH  (LENN)  IN  UORDS  OF  THE 

C  RECORDS  jANB  THE  OFFSETUN  UORDS)  TO  THE  START 

C  OF  THE  CONTROL  PART. 

C— INPUT  PARAMETERS: 

C  KPN-A  PARTITION  OF  THE  DATA  STORE.  KPN  IS  AN 
C  INDEX  OF  THE  KNPD  ARRAY. 

C— OUTPUT  PARAMETERS: 

C  LENN-LENGTH1IN  UORDS)  OF  THE  RECORDS  STORED  IN 
C  THE  KPN  SECTION  OF  THE  DATA  STORE. 

C  IOFF-NUMBER  OF  UORDS  TO  THE  FIRST  CONTROL  UORD 
C  (E.G.  KSTORD(KNPDCKPNHIOFF)  IS  THE  1ST 

C  UORD  OF  THE  1ST  RECORD  IN  SECTION  KPN) 
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SUBROUTINE  LHKDSD.NDB, ID3C3.IDE0) 

C — MODULE:  MOPADS/DBCS 

C— REFERENCES  HOARDS  VOLUME  5.13 

C--PURP0SE: 

C  TO  LINK  A  RECORD  INTO  THE  DATA  STORE.  <N‘iH£RIC 

C  OR  CHARACTER) . 

C — INPUT  PARAMETERS: 


NDB-DATA  5ASE( J-OORK’HS, 2-REFERENCE) 

IDBCF-UECSA  OF  The  RECORD  TO  BE  LINKEDUST  UORD  OF  CONTROL 
PAST) 

li'SO-DACSA  OF  THE  RECORD  IX  THE  DATA  STORE  TO  LINK  TO 
»■•  ») 

IF  iDB030,  LNKDSD  SEARCHES  THE  DATA  STORE  FOR 
AN  ENTRY  IN  THE  SAME  RECORD  CHAIN  AS  IDBCS. 


SUBROUTINE  LOCRD (NDB,IRU, LI ,L2,IR,IDBDL,I1 , I2,IERR,*,*) 

C— MODULE:  M0PAD5/DBCS 
C--REFERENCE:  MOPADS  VOLUME  5.13 
C— PURPOSE: 

C  LOCRD  RETURNS  THE  DBCSA  OF  DL  OR  DR  RECORDS  TO  BE  ACCESSED. 

C  IT  IS  CALLED  SEQUENTIALLY  WHEN  THE  ELEMENTS  OF  THE 

C  DL  OR  DR  SPAN  MORE  THAN  ONE  RECORD. 

C--INPUT  PARAMETERS: 


NDB-DATA  BASEM -UORKING, 2-REFERENCE) 

IRU-READ/URITE  FLAG  U-LOCRD  IS  BEING  CALLED  FOR  A 

READ  ACCESS,  2-LOCRD  IS  BEING  CALLED  FOR  A  URITE  ACCESS) 
LI ,L2— ELEMENTS  REQUESTED  BY  THE  USER.  IF  L2  IS  BEYOND 

THE  END  OF  THE  DL  OR  DR  AND  IRU=2,  THE  DL  OR  DR  UILL  BE 
EXTENDED. 

IR-FORCE  READ  FLAG< 1 -DO  NOT  FORCE  READ,  2-FORCE  READ 
FROM  DISKHNOT  APPLICABLE  IF  IRU=2) 


C— IHPUT/QUTPUT  PARAMETERS: 


IDBDL(2)-DBAA  OF  THE  DL  OR  DR.  IT  UILL  BE  SET  BY  '.OCRB 

TO  THE  DBAA  OF  THE  RECORD  WITH  ELEMENTS  11  TO  12. 
IT  MUST  NOT  BE  CHANGED  BETUEEN  CALLS. 
IDBDL<1)-RECQRD  NUMBER1  .LT.O  IF  CHARACTER) 
(2)-DBCSA 

II ,12-RETURNEP  AS  THE  ELEMENTS  CONTAINED  IN  THE  RECORD  AT 
IDBDL.  NO  FURTHER  CALLS  SHOULD  BE  MADE  UHEN  I2.GE.L2 
OR  IERR=6. 

ON  THE  FIRST  CALL  TO  LOCRD,  SEND  I2.LT.I1.  DO  NOT 
CHANGE  11  OR  12  BETUEEN  CALLS. 


C— OUTPUT  PARAMETERS: 


IERR-ERROR  CODE 
O-NO  ERROR 

4-ATTEMPT  TO  READ  PAST  END  OF  DL  OR  DR. 
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IDBDL  IS  THE  DBAA  OF  THE  LAST  RECORD  AND  II  AND  12 
ARE  RETURNED  AS  THE  ELEMENTS  ON  THIS  RECORD. 

7-FORCE  READ  OF  RECORDS  THAT  ARC  OUT  Of  DATE  ON  DISK. 
IN  CORE  VERSIONS  ARE  OVERWRITTEN. 

C— ALTERNATE  RETURNS: 

C  1 -IERR.NE.O. AND.IERR.NE.& 

C  2-IERR=6 

C  IF  BOTH  IERR=4  AND  7  ARE  APPLICABLE,  IERR  U1LL 

C  EQUAL  7  AND  ALTERNATE  RETURN  2  UILL  BE  TAKEN. 


FUNCTION  LSTORD(IDBCS) 

C--MODULE:  MOPADS'DBCS 
C — REFERENCE :  HOPADS  VOLUME  5.13 
C— PURPOSE: 

C  TO  DETERMINE  UHAT  PART  OF  THE  DATA  STORE  A  DBCSA 

C  LIES  IN.  LSTORD  RETURNS  AN  INDEX  TO  KNPD  SUCH 

C  THAT  KHPD(LSTORD).LE.IDliCS.LT.KNPD<LSTORD+1) 

c 

C — INFUT  PARAMETERS: 

C  IDBCC-A  DBCSA 


FUNCTION  HRANDI 11,12) 

C — MODULE:  MOPADS/DBCS 
C — REFERENCE:  MOPADS  VOLUME  5.13 
C — PURPOSE: 

C 

C  TO  GENERATE  AN  INTEGER  UNIFORMLY  DISTRIBUTED  BETUEEN 
C  11  AND  12. 

C 

C — INPUT  PARAMETERS: 

C  1 1 , 12-LOUER  AND  UPPER  BOUND  OF  THE  RANDOM  INTEGER 

C 

C--OUTPUT  PARAMETERS: 

C  MRAND-INTEOER  BETWEEN  II  AND  12. 
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FUNCTION  NCPARD(IPhR,TDBCSh) 

C — MODULES  MOPaDS/DECS 
C~ REFERENCE:  NOPADS  VOLUME  5.13 
C — PURPOSE: 

C  TO  RETURN  A  CONTROL  PARAMETER  FOR  A  BB  RECORD  IN  THE 
DATA  STORE* 

NCPARD  lo  INTENDED  FOR  INTERNAL  DBCS  USE  ONLY.  IT  DOES 
NO  ERROR  CHECKING  FOR  CORRECT  INPUT  PARAMETERS. 

—  INPUT  PARAMETERS: 

IPAR-THE  NUMBER  OF  THE  CONTROL  PARAMETER 

1- PREDECESSOR  DBA  ON  DISK 

2- 9BA  OF  THIS  RECORDCMAY  BE  NEGATIVE) 

3- SUCCESSOR  DBA  ON  DISK 

4- INITIAL  DBA  ON  DISK 

5- DBA  OF  THE  LDL 

6- INITIAL  DBA  OF  THE  OWNER  DIRECTORY 

7- ENTITY  TYPE,  1-DR,2-IDL,3-RDL,4-CDI.,5-LDL 

8- FOR  DL'S-THE  ROU(+)  OR  COLUMN(-)  DIMENSION. 

♦1  FOR  1-D  DL'S. 

FOR  RR'S-THE  RCU  DIMENSION 

9- INDEX  OF  THE  FIRST  ELEMENT  ON  THE  RECORD. 

10-INDEX  OF  THE  LAST  ELEMENT  ON  THE  RECORD. 


-1  ERROR 
-2  ERROR 

-3  SUCCESSOR  DBCSA  IN  CORE 
-4  PREDECESSOR  DBCSA  IN  CORE 
-5  DATA  BASE  (1  OR  2) 

-6  LOCATION  IN  CSTORD  CF  THE  DATA  PART  FOR 

CHARACTER  DL'S  AND  LDL  'S.  ERROR  FOR  NUMERIC  DL'S. 
IDBCSA-CURRtNT  DBCSA  OF  THE  DB  RECORD. 


SUBROUTINE  NEGNRD(IOBA) 

-MODULE:  MOPADS/DECS 
-REFERENCE:  MOPADS  VOLUME  5,13 
-FURPOSE: 

TO  SET  THE  RECORD  NUMBER  IN  CORE  NEGATIVE. 
THIS  INDICATES  THAT  THE  IN  CORE  RECORD 
CONTAINS  INFORMATION  NOT  YET  WRITTEN  TO  DISK. 
-INPUT  PARAMETERS: 

IDBA-DBCSA  OF  THE  RECORD 


SUBROUTINE  NEURCDINDI, IDBA, IERR,*) 

C— HODULEi  HOPADS/DBCS 
C— REFERENCE:  HOPADS  VOLUME  5.13 
C— PURPOSE: 

C  TO  OBTAIN  A  HEU  RECORD  NUMBER.  THE  RECORD  IS  HOT  READ 

C  NOR  LINKED  IN  ANY  UAY.  IF  A  RECORD  IS  CURRENTLY  NOT 

£  BE1N6  USED,  ITS  NUMBER  UILL  BE  RETRIEVED  FRON  THE 

C  ARL  AMD  USED.  IF  NO  RECORD  IS  AVAILABLE,  A  NEU  ONE  U2LL  BE 

C  CREATED.  ONE  RECORD  ALUAYS  EXISTS  IN  THE  ARL,  EVEN  IF 

C  IT  IS  EMPTY. 

C— INPUT  PARAMETERS: 

C  NDB-DB<  1~'JGRKIN6, 2-REF) 

C— OUTPUT  PARAMETERS: 

C  IOBA-DBA  OF  THE  NEU  RECORD (RECORD  NUMBER) 

C  T.ERR-ERR08  CODE 

C  2000-NO  MORE  RECORDS  AVAILABLE 

C— ALTERNATE  RETURNS: 

C  1-IERR.ME.C 


FUNCTION  NRD(IOPT,NR,ITY) 

C— MODULE:  MOPADS/DBCS 
C— REFERENCE:  MOPADS  VOLUME  5.13 
C— PURPOSE: 

C  DBCSA'S  HAVE  NEGATIVE  RECORD  NUMBERS  FOR  DATA  LISTS 

C  OF  TYPE  CHARACTER.  NRD  UILL  RETURN  THE  APPROPRIATE 

C  <♦  OR  -)  VALUE  OF  THE  RECORD  NUMBER. 

C 

C— INPUT  PARAMETERS: 

C  IOPT-OPTION 

C  1-RETURN  THE  CORRECT  SIGN  OF  THE  RECORD  NUMBER (SEE 

C  NRD) 

C  2-RETURN  IABS(NR)  (ITT  NOT  USED) 

C  NR-DBCSA  (IE  RECORD  NUMBER)  NR  MAY  BE  ♦  OR 

C  ITY-TYPE 

C  1-NU1ERIC,  2-CHARACTER 

C— OUTPUT  PARAMETERS: 

C  MRD-rOR  IOPT  =  t,  NRD  =  IhB5(NS<)  IF  ITY=1 

C  *-IABS(N8>  IF  IT*=2 

C  FOR  I0PT=2,  NRD=I ABS(NR) 
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SUBROUTINE  NXD(ND8,I0PT, IIRDL.IDIR, IC0ND,NCOND,NIB,IDRAA, 
-ID,IFOUND,HTY,IEmR,* ,*) 

-MODULES  H0PADS/88CS 
-REFERENCE:  H0P4DS  VOLUME  S. f 3 
-PURPOSE: 

NXB  MOVES  THE  CURRENT  BL  OR  DP  POSITION  OF  A  DIRECTORY 
TO  A  BL  OR  BR  THAT  SATISFIES  SPECIFIED  CONDITIONS. 

IF  NO  BL  OR  BR  SATISFYING  THE  CONDITIONS  IS  FOUND  OR  IF 
AN  ERROR  OCCURS,  THE  CURRENT  POSITION  IS  NOT  CHANGED. 

-INPUT  PARAMETERS: 

NDB-BATA  IASEM-UORKIN6, 2-REFERENCE) 

IOPT-OPTION 

t-RETURN  THE  CURRENT  POSITION  IF  I?  SATISFIES  THE 
CONDITION. 

2-THE  CURRENT  POSITION  IS  NOT  ELIGIBLE  Til  IE  FOUND. 
IDRDL-TTPE  TO  SEARCH  OVER 

1- DR'S 

2- DL'S 

IPIR-DIRECTIOM  OF  SEARCH 

1- FORUARD( AUAY  FROM  ONE) 

2- BACKUARDUQUARD  ONE,  l.E.  TOVARD  THE  BEGINNING  OF 
THE  LIST) 

I COND ( 3, NCOND) -CONDITIONS  TO  SATISFY.  'NCUND'  CONDITIONS  EXIST. 

ICOND( 1 , J)  IS  THE  ELEHENT  OF  THE  ID  TO  UHICH 
CONDITION  1CONDT2, J)  APPLIES.  ICOMDd  ,J)=»0 
MEANS  CONDITION  J  IS  NULL. 


IF  IC0ND(2,J)  IS 

.LE.O 

1 

2 

3 

4 

5 

6 


THEN  THE  CONDITION  IS 


HULLIANY  VALUE  IS  OK) 

ID  ELEMENT  ICQNBd,J)  .LT.  1C0ND(3,J> 
"  *  .IE.  •  " 

-  -  .EQ.  “  " 

•  *  .BE.  •  • 

"  *  .GT.  •  " 

*  -  .ME.  "  " 


E  6.  !C0ND(-,2>*(4,3,12)  MEANS  ID  ELEHENT  4 
MUST  EQUAL  12. 

IC0ND(-,3)*<5,0,0)  MEANS  ID  ELEHENT  S 
HAY  HAVE  ANY  VALUE. 


IF  NCOND'O,  ICOND  UILL  NOT  BE  USEB.  NXD  WILL 
SEARCH  IN  THE  DIRECTION  “IDIR"  FOR  THE  NEXT 
ENTRY  OF  TYPE  "IDRDL"  AND  RETURN  IT.  IF  IOPT*1 
NXD  UILL  RETURN  THE  CURRENT  POSITIQNdF  THERE  IS 
NO  CURRENT  POSITION,  ALTERNATE  RETURN  1  IS 
TAKEN.) 


c 

c 

c 

c 

c 

c 

c 


SEARCHING  HAT  IE  PERFORMED  ON  THE  EWTITV  TYPE 
AND  THE  DBA  AS  WELL.  LET  'LID'  IE  THE  LLN6TH 
OF  THE  ID'S.  THEN  ID  'ELEMENT'  LID+1 
IS  THE  TYPE  <1 -DIRECTORY ,2-2DL,3-RDL,4-CDL) . 
ELEMENT  HD  +  2  IS  THE  DBA  OF  THE  DL  OR  DR. 

TO  SEARCH  ON  THESE  USE  ICONDC J,1 >*LID+1  OR 
LID+2. 


C 

C  NII-AT  LEAST  THE  LENGTH  OF  THE  ID'S  OF  THE  DIRECTORY  AT  IDRAA 
C— INPUT/OUTPUT  PARAMETERS* 

C  IDRAA(4)-DRAA  OF  THE  DIRECTORY  TO  SEARCH 
C— OUTPUT  PARAMETERS* 


C 

C 

C 

C 

C 

C 

C 

C 

c 

c 

c 

c 

c 


II (MID) -IDENTIFIER  FOUND  BY  THE  SEARCH.  ZERO  V  ALTERNATE 
RETURN  1  IS  TAKEN.  IF  NID  IS  6REATER  THAN  THE 
LENGTH  OF  THE  ID'S,  THE  REMAINDER  IS  NOT  CHANGED. 
IFDUND(4)-DBAA  OR  DRAA  OF  THE  FOUND  ENTRY.  IF  IDRDL*2, 
ONLY  THE  FIRST  2  WORDS  OF  1FOUND  ARE  USED. 
IF0UNB*0  IF  ALTERNATE  RETURN  1  IS  TAKEN. 
HTY-COLUMH  POSITION  OF  THE  LAST  EMPTY  COLUMN  SEEN 
BEFORE  RETURN.  ZERO  IF  NONE. 

IERR 


O-NO  ERROR 
9-NID  TOO  SHORT 
15-IDRAA  NOT  A  DIRECTORY 
1 A-ICOND  NOT  ACCEPTABLE 
C— ALTERNATE  RETURNS* 

C  T  — HO  DL  OR  DR  SATISFYING  THE  CONDITIONS  WAS  FOUND 
C  2-1ERR.NE.0 


SUBROUTINE  OPNDBKNDB, ION, FILN,MAXR, NID, IERR, IOERR,*) 

C—  MODULE*  MOPADS/BBCS 
C— REFERENCE*  HOPADS  VOLUME  5.13 
C— PURPOSE* 

C  QPNDBD  WILL  OPEN  A  DB  FILE.  THE  DB  IS  OPENED  IN  READ-ONLY 
C  MODE 

C— INPUT  PARAMETERS* 

C  NDI-DATA  NASE ( 1 -UORKIHG ,2— REFEPEHCE > 

C  OPNDBD  WILL  CLOSE  AN  EXISTING  DB  OF  TYPE  ND8  BEFORE 

C  OPENING  THE  NEW  FILE. 

C  ION-OLB/NEU  OPTION 

C  1-CREATE  A  NEW  DB  ON  THE  SPECIFIED  FILE. 

C  2-OPEN  A  PREVIOUSLY  EXISTING  DB 

C  FIIN-FILE  NAHE(CHARACTER) 

C  MAXR-MAX  RECORD  NUMBER  FOR  THE  FILE 

C  .LE. O-USE  NO  LIMIT  IF  ION»1 .  IF  I0M*2,  USE  PREVIOUS 

C  VALUE. 

C  .GT. O-USE  HAXt  IF  ION*1.  IF  I0N*2,  U5E  THE  MAXIMUM  OF 
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HAXR  AND  THE  PREVIOUS  VALUE. 

NID-THE  NUMBER  OF  UGRDS/ID  FOR  THE  MASTER  DIRECTORY. 

USED  ONLY  IF  I0N=1.  (NID.GE.1) 

-OUTPUT  PARAMETERS: 

IERR-ERROR  CODE 
0-N0  ERROR 

2003-N0  PRIOR  CALL  TO  INITB 

3000- B0TH  DB'SdiQRKING  ANL-  REFERENCE)  HUST  HAVE  SAME 
RECORD  SJZE.  THIS  ERROR  OCCURS  IF  A  DB  IS  OPENED 
UITH  A  RECORD  SIZE  THAT  DOES  NOT  MATCH  THE  OTHER 
OPEN  DB. 

3001  — NEU  DB  DOES  NOT  HAVE  THE  CORRECT  CONTROL  PART  SIZE. 
3003-NEU  NB  DOES  NOT  HAVE  CORRECT  DIRECTORY  ADDRESS  SIZE. 

3001- SYSTEM  I/O  ERROR  OPENING  DB  OR  ACCESSING  PARAMETERS. 
INTEGER  PARAMETER  1  IS  THE  I/O  ERROR  CODE.  SEE  IOF.RR. 

NOTE:  ERRORS  3001  AND  3003  OCCUR  ONLY  IF  MODIFICATIONS 
ARE  MADE  TO  DBCS  tND  A  DB  CREATED  UITH  THE  EARLIER 
VERSION  ARE  RUN  UITH  THE  I.EU  VERSION. 

IOERR-SYSTEM  I/O  ERROR  CODE  IF  IERR=3004.  ZERO  OTHERWISE. 
-ALTERNATE  RETURNS: 

1-IERR.NE.O 


SUBROUTINE  PCD <NDB,IP1 , IU,CDL,NDL,IDBAA,IERR,*) 

-MODULE:  MOPADS/DBCS 
-REFERENCE:  MOPADS  VOLUME  5. 1 3 
-PURPOSE: 

TO  COPY  THE  CONTENTS  OF  THE  CHARACTER  ARRAY  CDL  TO  A  DATA  LIST 
OR  DIRECTORY. 

-INPUT  PARAMETERS: 

NDB-DATA  BASE  il -UORKING, 2-REFERENCE) 

IP1-THE  FIRST  ELEMENT  OF  THE  DL  OR  DR  TO  BE 
OVERURITTEN  UITH  DATA  FROM  CDL.  IF  IP1  IS 
BEYOND  THE  CURRENT  END  OF  THE  DL,  THE  DL  UILL 
BE  EXTENDED  (UITH  ZERO  VALUES  FOR  UNSPECIFIED 
•  ELEMENTS).  IF  IP1.LE.0,  RETURN  UITH  NO  ACTION. 

IU-FORCE  WRITE  FLAG  Ij 

J-DO  NOT  FORCE  URITE.  CHANGED  DL  OR  DR  MAY  EXIST 
ONLY  IN  CORE. 

2-FORCE  URITE  THE  CHANGES  TO  THE  DBF. 

THIS  OPTION  IS  IN  ADDITION  TO  THE  DB  PROTECTION  MODE. 

CDL ( NDL ) - THE  CHARACTER  ARRAY  UITH  VALUES  TO  BE  WRITTEN  TO  THE 
DATA  BASE.  NDL  ELEMENTS  UILL  BE  COPIED  FROM  CDL 
TO  THE  DATA  BASE. 

-INPUT/OUTPUT  PARAMETERS: 

IDBAA(2)-DBAA  OF  THE  DL  OR  DR.  IDBAA  MAY  BE  CHANGED  BY 
PCD  TO  REFLECT  CURRENT  DBCS  ADDRESSING. 
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— OUTPUT  PARAMETERS! 

lEkR-ERROR  COSE.  IF  IERR.NE.O,  THE  CONTENTS  OF  THE 
I9BAA  DL  OR  DR  ARE  UNPREDICTABLE. 

O-NO  ERROR 
1,2-DB  NOT  OPEN 
4-INVALID  ISSAA 

8-INVALID  WRITE  TO  READ  ONLY  Dl 
2000-NO  MORE  RECORDS  AVAILABE  IN  DBF. 
—ALTERNATE  RETURNS! 

1-IERR.NE.O 


SUBROUTINE  PC0LCD<NDB,NC3L,1R1 ,IR2, IW,CDL,HDL,IDBAA,IERR,*) 
-MODULE!  HOPADS/DBCS 
-REFERENCE!  HOPADS  VOLUME  5.13 
-PURPOSE! 

TO  COPY  DATA  FROM  THE  CHARACTER  ARRAY  CDL  TO  A  2-D  DL  IN 
THE  DATA  BASE. 

—INPUT  PARAMETERS: 

NBB-DATA  BASE  (1-UORK1NG, 2-REFERENCE) 

NCOL-THE  COLUMN  OF  THE  DL  TO  BE  COPIED 

1R1,IR2-R0U  ELEMENTS  IR1  TO  IR2  OF  COLUMN  NCOL  WILL  BE 

CHANGED.  IF  NDL.6T.1R2-I  .1+1 ,  THE  REMAINDER  OF  CDL 
WILL  NOT  BE  USED.  IF  NCL.LT. IR2-IR1«1,  ONLY 
NDL  ROW  ELEMENTS  WILL  BE  CHANGED.  SEE  1ERR.  IF 
IR2.LT.IR1  OR  TR1.LE.O,  RETURN  WITH  NO  ACTION 
IU-fORCE  URITE  FLAG 

1 - no  NOT  FORCE  URITE.  DL  CHANGED  IN  CORE  ONLY. 

2- FORCE  WRITE  THE  CHANGES  TO  DISK.  THIS  IS  IN  ADDITION  TO  THE 
DB  PROTECTION  MODE. 

CDL (NDL) -CHARACTER  ARRAY  UITH  VALUES  TO  BE  WRITTEN  TO  THE  DL. 
-INPUT/OUTPUT  PARAMETERS! 

IDBAA(2)-DBAA  OF  THE  DATA  LIST  OR  DIRECTORY.  IT  MUST  HAVE 

BEEN  OBTAINED  PREVIOUSLY.  IT  MAY  BE  CHANGED  IN  THIS 
SUBROUTINE  TO  REFLECT  CURRENT  DBCS  ADDRESSING. 

( 1 )-DBA,(2)-DBCSA 
-OUTPUT  PARAMETERS! 

IERR-ERROR  CODE 
O-NO  ERROR 

4- IDBAA  INVALID 

5- IR1  AHD/OR  IR2  INVALID 

8- ATTEMPT  TO  URITE  TO  READ  ONLY  DB 

9- ATTEMPT  TO  USE  INCORRECT  DIMENSIONS  TO  ACCESS  DB 

10-DL  NOT  CHARACTER 

-ALTERNATE  RETURNS! 

1-IERR.NE.O 
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SUBROUTINE  PC0LID(NDB,NC0L,IR1 ,1R2,1W, IBL,NDL, ID8AA,IERR,*) 
—MODULE*  HOPADS/DBCS 
—REFERENCE*  MOPABS  VOLUME  5.13 
— PURPOSE* 

TO  COPY  DATA  FROM  THE  INTEGER  ARRAY  IDL  TO  A  2-D  CL  IN 
THE  DATA  BASE. 

—INPUT  PARAMETERS* 

NDB-DATA  BASE  ( 1 -WORKING ,2-REFERENCE) 

NCOL-THE  COLUMN  OF  THE  BL  TO  BE  COPIED 

IR1 ,IR2-ROU  ELEMENTS  IR!  TO  IR2  OF  COLUMN  NCOL  WILL  BE 

CHANCED.  IF  NDL.GT.IR2-IRH1 ,  THE  REMAINDER  OF  IDL 
WILL  NOT  BE  USED.  IF  NDL.LT.IR2-IR1+1 ,  ONLY 
MOL  RQU  ELEMENTS  UILL  BE  CHAN6ED.  SEE  IERR.  IF 
IR2.LT. IS1  OR  IR1.LE.0,  RETURN  UITH  NO  ACTION 
IU -FORCE  WRITE  FLA6 

1- 00  NOT  FORCE  WRITE.  BL  CHANGED  IN  CORE  ONLY. 

2- FORCE  WRITE  THE  CHANGES  TO  DISK.  THIS  IS  IN  ADDITION  TO  THE 
DB  PROTECTION  MODE. 

IDL(NDL)-INTEGER  ARRAY  WITH  VALUES  TO  BE  WRITTEN  TO  THE  DL. 
—INPUT/OUTPUT  PARAMETERS* 

IDBAA<2)-DBAA  OF  THE  DATA  LIST  OR  BIRECTORY.  IT  MUST  HAVE 
BEEN  OBTAINED  PREVIOSLY.  IT  HAY  BE  CHANGED  IN  THIS 
SUBROUTINE  TO  REFLECT  CURRENT  DBCS  ADDRESS1N6. 

(1 )— DBA, (2)-DBCSA 
— OUTPUT  PARAMETERS* 

IERR-ERROR  CODE 
O-NO  ERROR 

4- IDBAA  INVALID 

5- IR1  AND/OR  1R2  INVALID 

8- ATTEMPT  TO  WRITE  TO  READ  ONLY  DB 

9- ATTEMPT  TO  USE  INCORRECT  DIMENSIONS  TO  ACCESS  DB 

10-DL  NOT  INTE6ER 

— ALTERNATE  RETURNS* 

1 -IERR.NE.0 


SUBROUTINE  PC0LRD(NDB,NCGL,IR1 , IR2, IU,RDL,NDL, IDBAA,IERR,*) 
—MODULE:  MOPADS/DBCS 
— REFERENCE*  MOPADS  VOLUME  5.13 
—PURPOSE* 

TO  COPT  DATA  FROM  THE  REAL  ARRAY  RDL  TO  A  2-D  DL  IN 
THE  DATA  BASE. 

—  INPUT  PARAMETERS* 

C  NDB-DATA  BASE  (1-WORKING, 2-REFERENCE) 
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C  NCOL-THF.  COLUMN  OF  THE  DL  TO  IE  COr  IED 
C  1R1,IR2~R0U  ELEMEHTS  IR1  TO  IR2  OF  COLUMN  NCOL  UILL  IE 
C  CHANGE!.  IF  NDL.6T. IR2-IR1 ♦! ,  THE  REMAINDER  OF  RDL 

C  UILL  HOT  BE  USED.  IF  NDL.LT.IR2-IR1-M ,  ONLY 

C  NDL  RUU  ELEMENTS  UILL  BE  CHANGED.  SEE  IERR.  IF 

C  IR2.LT. IR1  OR  IR1.LE.O,  RETURN  UITH  HO  ACTION 

C  IU-FORCE  URITE  FLAG 

C  1-DO  NOT  FORCE  URITE.  DL  CHANGED  IN  CORE  ONLY. 

C  2-FORCE  URITE  THE  CHANGES  TO  DISK.  THIS  IS  IN  ADDITION  TO  THE 

C  PB  PROTECTION  NODE. 

C  RDL(NDL)-REAL  ARRAY  UITH  VALUES  TO  BE  WRITTEN  TO  THE  DL. 

C — IMPUT/OUTPUT  PARAMETERS! 

C  ID8AA(2)-DBAA  OF  THE  DATA  LIST  OR  DIRECTORY.  IT  MUST  HAVE 

C  BEEN  OBTAINED  PREVIOSLY.  IT  HAT  BE  CHANGED  IN  THIS 

C  SUBROUTINE  TO  REFLECT  CURRENT  DBCS  ADDRESS1HG. 

C  (1 >-DBA, (2)-DBCSA 

C--GUTPUT  PARAMETERS! 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  4-ID8AA  INVALID 

C  5-IR1  AHD/OR  IR2  INVALID 

C  8-ATTEHPT  TO  URITE  TO  READ  ONLY  DB 

C  9-ATTEMPT  TO  USE  INCGRRECT  DIMENSIONS  TO  ACCESS  Dl 

C  10- DL  HOT  REAL 

C—ALTERNAfE  RETURNS! 

C  1-IERR.NE.0 

C 


SUBROUTINE  riD(NDI,IP1 ,IU,IDL, NDL. IDBAA, IERR, *> 

C— MODULE!  MOPADS/DBCS 
C — REFERENCE:  MCPADS  VOLUME  5.13 
C — PURPOSE: 

C  TO  COPT  THE  CONTENTS  OF  THE  ARRAT  IBL  TO  AN  INTEGER  DATA  LIST 

C  OR  DIRECTORY. 

C--INPUT  PARAMETERS! 

C  HD6-DATA  BASE  < 1 -WORKING ,2-REFERENCE) 

f  IP1-THE  FIRST  ELEMENT  OF  THE  DL  OR  DR  TO  BE 

?  OVERWRITTEN  UITH  DATA  FROM  IDL.  IF  IP1  IS 

t  BEYOND  THE  CURRENT  END  OF  THE  DL,  THE  DL  UILL 

C  BE  EXTENDED  (UITH  ZERO  VALUES  FOR  UNSPECIFIED 

C  ELEMENTS).  IF  IPl.LE.O,  RETURN  UITH  NO  ACTION. 

C  IU-FORCE  URITE  FLAG 

C  1-DO  NOT  FORCE  URITE.  CHANGED  DL  OR  DR  MAT  EXIST 

C  ONLY  IN  CORE. 

C  2-FORCE  URITE  THE  CHANGES  TO  THE  DBF. 

C  THIS  C?TION  IS  IN  ADDITION  TO  THE  T-3  PROTECTION  NODE, 

f.  IDUKDD-THE  INTEGER  ARRAY  UITH  VALUi'S  TO  BE  URITTEN  TO  THE 
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C  SATA  IASE.  NDL  ELEMENTS  UILL  IE  COPIED  FROM  ILL 

C  TO  THE  DATA  BASE. 

C—INPUT/OUTPUT  PARAMETERS: 

C  IDBAA(2)-DBAA  OF  THE  OL  OR  DR.  IDBAA  HAY  BE  CHANGED  BY 
C  PID  TO  REFLECT  CURRENT  DBCS  ADDRESSING. 

C— OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE.  IF  IERR.NE.O,  THE  CONTENTS  OF  THE 

C  IDBAA  DL  OR  DR  ARE  UNPREDICTABLE. 

C  O-NO  ERROR 

C  1,2-DB  NOT  OPEN 

C  4-INVALID  IDBAA 

C  8-INVALID  WRITE  TO  READ  ONLY  DC 

C  2000-N0  MORE  RECORDS  AVA1LABE  IN  DBF. 

C — ALTERNATE  RETURNS: 

C  1-IERR.NE.O 

C 


SUBROUTINE  PLBDLDCNDB, IDBAA, LABEL, IERR,*> 

C— MODULE:  HOPADS/DBCS 
C — REFERENCES  HOPADS  VOLUME  5.13 
C — PURPOSE: 

C  TO  ASSIGN  A  LABEL  TO  A  DL.  PLBDLP  UILL  OVERURITE  A 
C  PREVIOUS  DL  LABEL. 

C 

C— INPUT  PARAMETERS: 

C  NDB-DATA  BASE! 1-UORKING, 2-REFERENCE) 

C  IDBAA(2)-DBAA  OF  A  RECORD  OF  THE  DL. 

C  LABEL-NEU  DL  LABEL(CHARACTER) .  DL  LABELS  UILL  BE 

C  TRUNCATED  TO  25  CHARACTERS. 

C— OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  O-HO  ERROR 

C  12- IDBAA  HOT  A  DL. 

C — ALTERNATE  RETURNS: 

C  1-IERR.NE.O 


SUBROUTINE  ^BELD( NDB, IRC, IL!,IL2, LABEL, NLBL, IDBAA, IERR,») 
C— MODULE:  NOPALS/  DBCS 
C— REFERENCE:  HOPADS  VOLUME  5.13 
C— PURPOSE: 

C  PLBELD  SETS  LABELS  OF  DL  ELEMENTS. 

C — INPUT  PARAMETERS: 

C  NDB-DATA  BASE (1 -WORKING, 2-REFERENCE) 
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C  IRC-ROU/COLUHN  INBIlATQR 

C  IRC.GT.O-ROU  IRC 

C  IRC.LT.O-CULUMN  (-IRC) 

C  1RC»0  -A  1-o  I  AT A  LIST 

C  IL1 ,IL2-£LEMENT  NUMBERS 

C  I8C.GT .O-THESE  ARE  THE  FIRST  AND  LAST  COLUHNS 

C  OF  ROU  IRC  UKOSE  LABELS  ARE  TO  BE  CHAN6ED. 

C  IRC.LT  O-THESE  ARE  THE  FIRST  AND  LAST  ROUS  OF  COLUMN 

C  -IRC  UHOSE  LABELS  ARE  TO  BE  CHANGED. 

C  IRC. EQ. O-THESE  ARE  THE  FIRST  AND  LAST  ELEMENTS  UHOSE 

C  LABELS  ARE  TO  BE  CHANGED. 

C  LABEL (NLBL) -CHARACTER  ARRAY  CONTAINING  LABELS. 

C  IF  IL2-IL1+1  .6T.NLBL,  ONLY  NLBL  LABELS  UILL 

C  BE  CHABGED. 

C  IF  IL2-IL1 *1 .LT.NLBL,  ONLY  IL2-1L1+1  ELEMENTS  OF 

C  LABEL  UILL  BE  REFERENCED. 

C— INPUT/OUTPUT  PARAMETERS: 

C  IDBAAC21-DBAA  OF  THE  DL  UHOSE  ELEMENTS  LABELS  ARE  TO  BE  SET. 
C--OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  5,?. 12 

C — ALTERNATE  RETURNS: 

C  1-IERR.NE.O 

C 


SUBROUTINE  PLINKD<NDB,IDRAA,IBQAA,NID,IERR,0 
C— MODULE:  MOPADS/DBCS 
C— REFERENCE:  HOPADS  VOLUME  5.13 
C— PURPOSE: 

C  PLINKD  UILL  RETURN  THE  DRAA  OF  THE  OUNER  OF  A  DL  OR  DR. 

C 

C--INPUT  PARAMETERS: 

C  NDB-DATA  BASEd-UORKING, 2-REFERENCE) 

C  1 DRAA (4)-DRAA (DIRECTORY)  OR  DBAA(DL)  OF  THE  DR  OR  DL  UHOSE 

C  OUNER  IS  TO  BE  FOUND.  IF  IT  IS  A  DL,  IDRAA  NEED  BE 

C  DIMENSIONED  ONLY  TO  2. 

C— OUTPUT  PARAMETERS: 

C  IDOAA<  4 ) -THE  DRAA  OF  THE  OUNER  DIRECTORY.  IF  IDRAA  HAS  NO 

C  OUNER,  I  DO A A  < 1 )=0. 

C  NID-NUMBER  OF  UORDS  IN  THE  ID  OF  IDRAA 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C 

C — ALTERNATE  RETURNS: 

C  1-IERR.NE.O 
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SUBROUTINE  PO$DRD(NDB,IBE,IDRDL,IDRAA,lERR,*,-: ) 
—MODULES  MOPADS/IlRCS 
--REFERENCE:  NOPADS  VOLUME  5.13 
—PURPOSE: 

POSDRD  U1LL  POSITION  A  DR  AT  ITS  BEGINNING  OR  END(FQR 
OUNED  DL'S  OR  DR'S) 

—INPUT  PARAMETERS: 

NDB-DATA  BASE (1-UORKING, 2-REFERENCE) 

IIE-DIRECTION 

1- POSITION  AT  BESIKNING 

2- POSITION  AT  END 
IDRDl-TTPE  OF  SEARCH 

1- DR'S 

2- DL'S 

-INPUT/OUTPUT  PARAMETERS: 

IDRAA(4)-DRAA  OF  THE  DIRECTORY 
-OUTPUT  PARAMETERS: 

IERR-ERROR  CODE 
O-NO  ERROR 
-ALTERNATE  RETURNS: 

1- IDRAA  HAS  NO  ENTRIES  OF  TYPE  IDRDL 

2- IERR.NE.O 


SUBROUTINE  PRD(NDB,IF1 ,  IU,RDL,NDL,IDBAA,IERR,*) 

-MODULE:  MOPADS/DBCS 
-REFERENCE:  HOPADS  VOLUME  5.13 
-PURPOSE: 

TO  COPY  THE  CONTENTS  OF  THE  ARRAY  RDL  TO  A  REAL  DATA  LIST 
OR  DIRECTORY. 

-INPUT  PARAMETERS: 

NDB-DATA  BASE  (1-UORKING, 2-REFERENCE) 

IP1-THE  FIRST  ELEMENT  OF  THE  DL  OR  DR  TO  BE 
OVERURITTEN  WITH  DATA  FROM  RDL.  IF  IP1  IS 
BEYOND  THE  CURRENT  END  OF  THE  DL,  THE  DL  UILL 
BE  EXTENDED  (UITH  ZERO  VALUES  FOR  UNSPECIFIED 
ELEMENTS).  IF  IPJ.LE.O,  RETURN  UITH  NO  ACTION. 
IU-FORCE  WRITE  FLAG 

1- DO  NOT  FORCE  URITE.  CHANGED  DL  OR  DR  MAY  EXIST 
ONLY  IN  CORE. 

2- FORCE  URITE  THE  CHANGES  TO  THE  DBF. 

THIS  OPTION  IS  IK  ADDITION  TO  THE  CB  PROTECTION  MODE. 
RDL C HDL ) -THE  REAL  ARRAY  UITH  VALUES  TO  BE  WRITTEN  TO  THE 
DATA  BASE.  NDL  ELEMENTS  UILL  BE  COPIED  FROM  RDL 
TO  THE  DATA  BASE. 
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C--INPUT/OUTPUT  PARAMETERS: 

C  IDBAA(2)-LoAA  OF  THE  Dl  OR  DR.  IDBAA  HAY  BE  CHANGED  BY 
C  PRD  TO  REFLECT  CURRENT  CBCS  ADDRESSING. 

C — OUTPUT  PARhMETERS: 

C  IEHR-ERROR  CODE.  IF  IERR.NE.O,  THE  CONTENTS  OF  THE 

C  IDBAA  DL  OR  DR  ARE  UNPREDICTABLE. 

C  O-NO  ERROR 

C  1,2-DB  NOT  OPEN 

C  4-INVALID  IDBAA 

C  8-INVALID  URITE  TO  READ  ONLY  DB 

C  2000-NO  fiORE  RECORDS  AVAILABE  IN  DBF. 

C— ALTERNATE  RETURNS: 

C  1-IERR.NE.O 

C 


SUBROUTINE  PROTD(NDB,KPROT,I£RR,») 

C— HODULE:  MOPADS/DBCS 
C — REFERENCE:  HOPADS  VOLUHE  5.13 
C — PURPOSE: 

C  TO  SET  THE  PROTECTION  TODE  FOR  THE  OB 

C 

C— INPUT  PARAMETERS: 


C 

C 

C 

C 

C 

C 


NDB-DB( 1-UORKINS,  2-REF) 
KPROT-PROTECTIQN  CODE 

1- READ  ONLY 

2- URITEtSAFE ) 

3- URITE1LQ0SE) 

4- URITE(UNSAFE) 


C— OUTPUT  PARAMETERS: 

C  ,,  IERR-ERROR  CODE 

C  jlj  O-NO  ERROR 

C  I  !  1,2 

C — ALTERNATE  RETURNS: 

C  I  i  1-IERR.NE.O 


SUBROUTINE  PROUCD1NDB,NROU,IC1  ,IC2,IUf CDL,NDL, IDBAA, IERR,*> 
C— HODULE:  HOPADS/DBCS 
—REFERENCE:  HOPADS  VOLUME  5.13 
—PURPOSE: 

TO  COPr  DATA  FROM  THE  CHARACTER  ARRAY  CDL  TO  A  2-D  DL  IN 
THE  DATA  BASE. 

—  INPUT  PARAMETERS: 

NDB-DATA  BASE  (1-UORKING, 2-REFERENCE) 

NROU-THE  ROU  OF  THE  DL  TO  BE  COPIED 
C  ICl , IC2-C0LUMN  ELEMENTS  IC1  TO  1C2  OF  ROU  NROU  UILL  BE 
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CHANGED.  IF  NDL.GT. IC2-IC1 +1 ,  THE  REMAINDER  OF  CDL 
WILL  NOT  BE  USED.  IF  NDL.LT.IC2-IC1+1 ,  ONLY 
NDL  COLUMN  ELEMENTS  WILL  BE  CHANGED.  SEE  1ERR.  IF 
IC2.LT. IC1  OR  ICJ.LE.O,  RETURN  UITH  NO  ACTION 
IU-FORCE  WRITE  FLAG 

1- DO  NOT  FORCE  WRITE.  DL  CHANGED  IN  CORE  ONLY. 

2- FORCE  WRITE  THE  CHANGES  TO  DISK.  THIS  IS  IN  ADDITION  TO  THE 
DB  PROTECTION  MODE. 

CDL (NDL) -CHARACTER  ARRAY  WITH  VALUES  TO  BE  WRITTEN  TO  THE  DB. 
--INPUT/OUTPUT  PARAMETERS: 

IDBAA(2)-DBAA  OF  THE  DATA  LIST  OR  DIRECTORY.  IT  MUST  HAVE 
BEEN  OBTAINED  PREVIOSLY.  IT  KAY  BE  CHANGED  IN  THIS 
SUBROUTINE  TO  REFLECT  CURRENT  DECS  ADDRESSING. 

( 1 )-DBA, (2)-DBCSA 
— OUTPUT  PARAMETERS: 

IERR-ERROR  CODE 
O-NO  ERROR 

4- IDBAA  INVALID 

5- IC1  AND/OR  IC2  INVALID 

8- ATTEHPT  TO  WRITE  TO  READ  ONLY  DB 

9- ATTEMPT  TO  USE  INCORRECT  DIMENSIONS  TO  ACCESS  DB 

1 0— DL  NOT  CHARACTER 

-ALTERNATE  RETURNS: 

1-IERR.NE.O 


SUBROUTINE  PROW I D < NUB , NROU , I C 1 ,IC2,IW,IDL,NDL,IDBAA,IERR,*> 
-MODULE:  MOPADS/DBCS 
-REFERENCE:  MOPADS  VOLUME  5.13 
-PURPOSE: 

TO  COPY  DATA  FROM  THE  INTEGER  ARRAY  IDL  TO  A  2-D  DL  IN 
THE  DATA  BASE. 

-INPUT  PARAMETERS: 

NOB-DATA  BASE  ( 1 -WORKING .2-REFERENCE ) 

NROU- THE  ROW  OF  THE  DL  TO  BE  COPIED 

IC1  ,IC2-C0I,UMN  ELEMENTS  IC1  TO  IC2  OF  ROW  NROU  UILL  BE 

CHAINED.  IF  NDL.8T .IC2-IC1+1 ,  THE  REMAINDER  OF  IDL 
WILL  NOT  BE  USED.  IF  NDL.LT. IC2-IC1 +1 ,  ONLY 
NDL  COLUMN  ELEMENTS  WILL  BE  CHANGED.  SEE  IERR.  IF 
IC2.LT. IC1  OR  IC1.LE.Q,  RETURN  UITH  NO  ACTION 
IW-FORCE  WRITE  FLAG 

t-DO  NOT  FORCE  WRITE.  DL  CHANGED  IN  CORE  ONLY. 

2-FORCE  URITE  THE  CHANGES  TO  DISK.  THIS  IS  IN  ADDITION  TO  THE 
DB  PROTECTION  MODE. 

IDL (NDL)-INTEGER  ARRAY  WITH  VALUES  TO  BE  WRITTEN  TO  THE  DB. 


C— INPUT/OUTPUT  PARAMETERS: 
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IDBAA(2>-DBAA  OF  THE  DATA  LIST  OR  DIRECTORY.  IT  MUST  HAVE 

BEEN  OBTAINED  PREVIOSLY.  IT  MAT  BE  CHANCED  IN  THIS 
SUBROUTINE  TO  REFLECT  CURRENT  DBCS  ADDRESSING. 

(1 )— DBA, <2>  — DBCSA 
— OUTPUT  PARAMETERS: 

IERR-ERROR  CODE 
O-NO  ERROR 

4- IDBAA  INVALID 

5- IC1  AND/OR  IC2  INVALID 
O-ATTEMPT  TO  URITE  I?  READ  ONLY  DB 

9-'TTEMPT  TO  USE  INCORRECT  DIMENSIONS  TO  ACCESS  DB 
1 0-i)L  NOT  INTEGER 
--ALTERNATE  RETURNS: 

1-IERR.NE.O 


SUBROUTINE  PftOURD(NDB,NPGUf IC1 , IC2, IU,RDL,NDL, IDBAA , IERR,*) 
-MODULE:  MOPADS/DBCS 
-REFERENCE:  MOPADS  VOLUME  5.13 
-PURPOSE: 

TO  COPT  DATA  FROM  THE  REAL  ARRAY  RDL  TO  A  2-D  DL  IN 
THE  DATA  BASE. 

-INPUT  PARAMETERS: 

NDB-DATA  BASE  (1-UORKINC, 2-REFERENCE) 

NROU-THE  ROU  OF  THE  DL  TO  BE  COPIED 
IC1 , IC2-COLUMN  ELEMENTS  IC1  TO  IC2  OF  ROU  NROU  UILL  BE 

CHANGED.  IF  NBL.GT.IC2-IC1+1 ,  THE  REMAINDER  OF  RDL 
UILL  NOT  BE  USED.  IF  NDL.LT. 1C2- ’Cl +1 ,  ONLY 
NDL  COLUMN  ELEMENTS  UILL  BE  CHANGED.  SEE  I  ERR.  IF 
IC2.LT. IC1  OR  IC1.LE.O,  RETURN  WITH  NO  ACTION 
IU-FOPCE  URITE  FLAG 

1- DO  NOT  FORCE  URITE.  DL  CHANGED  IN  CORE  ONLY. 

2- FOPCE  URITE  THE  CHANGES  10  DISK.  THIS  IS  IN  ADDITION  TO  THE 
DB  PROTECTION  MODE. 

RDL ( NDL ) -REAL  ARRAY  UITH  VALUES  TO  BE  WRITTEN  TO  THE  DB. 
-INPUT/OUTPUT  PARAMETERS: 

IDBAA(2)-DBAA  OF  THE  DATA  LIST  OR  DIRECTORY.  IT  MUST  HAVE 
BEEN  OBTAINED  PREVIOSLT.  IT  MAY  BE  CHANGED  IN  THIS 
SUBROUTINE  TO  REFLECT  CURRENT  DBCS  ADDRESSING. 
<1)-BBA,(2>-DBCSA 
-OUTPUT  PARAMETERS: 

IERR-ERROR  CODE 
O-NO  ERROR 
C  4-IDBAA  INVALID 

C  5-IC1  AND/OR  IC2  INVALID 

C  8-ATTEMPT  TO  URITE  TO  READ  ONLY  DB 

C  9-ATTEMPT  TO  USE  INCORRECT  DIMENSIONS  TO  ACCESS  DB 
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C  10-DL  POT  REAL 

C- -ALTERNATE  RETURNS; 

C  1-1 ERR . ME . 0 
C 


SUBROUTINE  PRTDLD(NDB,HSG,IL1 ,IL2,IHEAD,IDBAA,IERR,*) 

C — HODULE :  HOPADS/DBCS 
C — REFERENCE;  MCPADC  VOLUME  5.13 
C — PURPOSE; 

C  PRTDLD  PRINTS  THE  CONTENTS  OF  A  DATA  LIST  ON  THE  DBCS  OUTPUT 
C  FILE. 

C— INPUT  PARAMETERS; 

C  NDB-DA'.'A  BASEM-UORKING, 2-REFERENCE) 

C  HSG-(CKANACTER)  MESSAGE  TO  BE  PRINTED  PITH  THE  DL. (NOT  PRINTED 
C  IF  BLANK) 

C  IL1 , IL2-FIRST  AHD  LAST  ELEMENTS  TO  PRINT. 

C  IL1*0  STARTS  AT  FIRST  ELEMENT. 

C  IL2-0  MEANS  PRINT  TO  END 

C  FOR  1-D  DL'S,  IL1  AND  IL2  ARE  ELEMENTS 

C  FOR  2-D  COLUMN  ORIENTED  DL'S,  1L1  AND  IL2  ARE  COLUMN 

C  NUMBERS. 

C  FOR  2-D  ROU  ORIENTED  DL'S,  IL1  AND  2L2  ARE  ROU  NUMBERS 

C  1HEAD-HEADER  OPTION 

C  1-YES 

C  2-NO 

C— INPUT/OUTPUT  PARAMETERS: 

C  IDBAA(2)-DBAA  OF  THE  DL 

C— OUTPUT  PARAMETERS; 

C  IERR-ERRPR  CODE 

C  O-NO  ERROR  - 

C  12-IDBAA  NOT  A  DL 

C  4010-DL  NOT  IN  SPECIFIED  DR 

C— ALTERNATE  RETURNS; 

C  1-IERR.NE.O 


SUBROUTINE  PRTDRD(NDB, JOPT,HSG, IBRAA, IERR,0 
— MODULE;  MOPADS/DBCS 
--REFERENCE:  HOPADS  VOLUME  5.t3 
—PURPOSE: 

PRTDRD  WILL  PRINT  THE  CONTENTS  OF  A  DIRECTORY  ON  THE  DBCS  OUTPUT 
FILE. 

—  INPUT  PARAMETERS; 

NDB-DATA  BASEL  1 -UCRKINS, 2-REFERENCE) 
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c  icpt-qption 

C  1 -PRINT  OUNEB  DIREC.0RIE3 

C  2-PRINT  OWNED  RATA  LISTS 

C  0*PRINT  IQTH 

C  MSG-(CHARACTER)  MESSAGE  TO  BE  PRINTED<HO«E  IK  BLSMK) 

C— INPUT/OUTPUT  PARAMETERS! 

C  IDRAA(4)-DRAA  OK  THE  BIRECTORT 

C— OUTPUT  PARAMETERS! 

C  IERR-ERROR  CODE 

C  O-HO  ERRuS 

C  1S-10SAA  NUT  A  BIRECTORT 

C— ALTERNATE  RETURNS: 

C  1-IERR.NE.O 


SUBROUTINE  PSAFS( I  DBA A, SAF, I  ERR,*) 

C--MOBULE:  MOPADS/DBCS 
C— REFERENCE:  HOPADS  VOLUME  5.13 
C— PURPOSE! 

C  TO  SET  THE  SAF  OF  A  DL  Oft  DR  PECORD  TO  A  SPECIFIED  VALUE. 
C— INPUT  PARAMETERS! 

C  IDBAA(2)-CURRENT  DBAA  OF  THE  DL  DR  DR  RECORD.  AN 
C  ERROR  RESULTS  IF  IDBAA  IS  NOT  CURRENT. 

C  SAF-VALUE  OF  THE  SAF  FOR  THE  RECORD  AT  2DFAA. 

C— OUTPUT  PARAMETERS! 

C  IERR-ERROR  CODE 

C  0*NQ  ERROR 

C  1 1-IDBAA  NOT  CURRENT (VALUE  OF  SAF  NOT  CHANGED) 

C-ALTERNATE  RETURNS* 

C  1-IERR.NE.O 


SUBROUTINE  PSTORD 
C— MODULE:  MOPADS/DBCS 
C— REFERENCE:  MOPADS  VOLUME  5.13 
C— PURPOSE: 

C  PSTORD  PRINTS  THE  CONTENTS  OF  THE  DBC3  DATA  STORE  TO  THE 
C  DECS  OUTPUT  FILE. 

C 
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SUBROUTINE  RCD(NDI,IJ)BA,ICP,DP,IERR,*) 

C — MODULE:  H0PA3S/B8CS 
C— REFERENCE:  H0PAB3  VOLUME  5.13 
C— PURPOSE: 

C  TO  READ  A  CHARACTER  RECORD 

C--1HPUT  PARAMETERS: 

C  AD J-9B ( 1 -WORKING,  2-REF) 

C  IVBA-BBA<RECORD  NUMBER) 

C— OUTPUT  PARAMETERS: 

C  TCP ( NUCPO ) -ARRAY  FOR  CONTROL  PART  OF  THE  RECOR* 

f  BP  (NCliP*) -CHARACTER  VARIABLE  FOR  THE  DATA  PART  OF  THE  RECORD 

C  IERR-E8P2R  CODE 

C  O-NO  ERROR 

C  1 ,2,3004,4002,4004,4003 

C— ALTERNATE  RETURNS:  i 

C  1-1ERR.NE.0 


SUBROUTINE  RD<NDB,ITYPtNR, IDBAR,IERR,*> 

C— NODULE:  HOPADS/DBCS 
C--REFERENCE:  HOPADS  VOLUME  5.13 
C — PURPOSE: 

C  RD  READS  A  RECORD  FROM  THE  DB 

C— INPUT  PARAMETERS: 

C  NDB-DB< 1 -WORKING, 2-REF) 

C  ITYP-RECORD  TYPE ( 1 -NUMERIC, 2-CKARACTER) 

C  NR-RECORD  NUMBER 

C  IDBARO-DBCSA'S  OF  CONTROL  AND  DATA  PARTS, RESPECTIVELY 

C— OUTPUT  PARAMETERS*:  9 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C— ALTERNATE  RETURNS: 

C  1-1  ERR .  HE . 0 


SUBROUTINE  RETCH9(NDB,I0PT, IDBAA,IERR,*) 

C— MODULE:  HOPADS/DBCS 
C— REFERENCE:  MCPADS  VOLUME  5.13 
C— PURPOSE: 

TO  RETURN  A  CHAIN  OF  DISK  RECORDS  TO  THE  ARL 
STARTING  AT  1DSAA. 

— INPUT  PARAMETERS: 

NDB-DATA  BASE  M-UORKING, 2-REFERENCE) 


i 
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U-91 


C  IOPT-OPTION 

C  O-RETURN  ENTIRE  CHAIN 

C  1-RETURN  ALL  RECORDS  PRIOR  TO  ITBAA 

C  2-RETURN  ALL  RECORDS  AFTER  I  DBA  A 

C  IDBAA(2)-DBAA  OF  A  RECORD  IN  THE  CHAIN.  THE  RECORD  MUST 

C  EXIST  IN  THE  DATA  STORE  AND  IDBAT  MUST  BE  CURRENT 

C  (IDBAA(2)  CORRECT).  IDBAA  IS  UNCHANGED  CM 

C  RETURN. 

C— OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  1,2, PLUS  OTHERS 

C— ALTERNATE  RETURNS: 

C  t -IERR.NE.0 

C 


SUBROUTINE  RETRCD < NOB , I OPT , I SB A , IERR , * > 

C— NODULE:  MOPADS/DBCS 
C— REFERENCE:  HQPADS  VOLUME  5.13 
C— PURPOSE: 

C  TO  RETURN  A  RECORD  TO  THE  ARL.  RETRCD  PUTS  THE 

C  RECORD  IN  THE  ARL.  IT  UILL  OPTIONALLY  UNLINK 

C  THE  DATA  STORE  SPACE  AHD  MAKE  IT  AVAILABLE,  AND  UNLINK 

C  THE  RECORD  ON  DISK.  FOR  UNLINKING, THE  RECORD  MUST 

C  EXIST  IN  THE  DATA  STORE. 

C  —  INPUT  PARAMETERS: 

C  NDS-DB(1-UOkKlNG, 2-REF) 

C  IOPT-OPTION 

C  1 -RETURN  RECGRD  2 DBA < 1 )  TO  THE  ARL  ONLY 

C  2-RETURN  THE  RECORD  TO  THE  ARL  AND  UNLINK  ON 

C  DISK  AND  IN  DATA  STORE. (IF  IT  EXIST  IN  THE  STORE) 

C  I  DBA  C  2 ) -THE  CURRENT  DBAA  Or  THE  RECORD  ON  INPUT .  IDI«A(2) 

C  IS  NOT  USED  IF  10PIM. 

C— OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  8 

C  3006 

C--ALTERNATE  RETURNS: 

C  1  -IERR.NE.0 


SUBROUTINE  RID(NDB,IDBA,ICP,IDP,iERRf*) 
C--MODUIE:  H0PAPS/D8CS 
C—REFERENCE:  MOPADS  VOLUME  5.13 


C — PURPOSE: 

C  TO  READ  AN  INTEGER  RECORD  FROM  A  DB 

C — INPU1  PARAMETERS: 

C  NDB-DB<1 -WORKING,  2-REF) 

C  IDBA-DBA(R£COnD  NUMBER) 

C — OUTPUT  PARAMETERS: 

C  ICP(MUCPD)-ARRAY  FOR  CONTROL  PART  OF  RECORD 

C  IDP(NUDPD)-ARRAT  FOR  THE  DATA  PART  OF  THE  RECORD 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  1,2,3004,4002,4004,4005 

C—ALTERNATE  RETURNS: 

C  1-1ERR.NE.0 


SUBROUTINE  R:.OIRD(IOPT,KODE8,KRKDL,KRKDR,KODE5) 

C--NDDULE:  MOPADS/DBCS 
C — REFERENCE:  NOPADS  VOLUME  5.13 
C—  PURPOSE: 

C  RKDIRD  COMPUTES  THE  RANKING  CODE  FOR  CONTROL  WORD 
C  5  OF  DIRECTORIES  FROM  THE  DIRECTORY  AND  DATA  LIST  RANKING 
L  CODES  OR  VICE  VERSA. 

C--1NPUT  PARAMETERS: 

C  IOPT-OPTIUN 

C  1-COMPUTE  CONTROL  WORD  5  FROM  THE  RANKING 

C  CODESUNPUT-KRKDL,KRKDR,OUTPUT-KODE5) 

C  2-COMPUTE  INDIVIDUAL  RANKING  CODES  FROM 

C  CONTROL  UQRD  5< INPUT -KODE 5, OUTPUT -KSKDL  AND  KRKDR) 

C  K0DE8-VALUE  OF  C0N7R0L  WORD  8  OF  THE  DIRECTORY 

C— INPUT/OUTPUI  PARAMETERS: 

C  KRKDL-THE  INDIVIDUAL  RANKING  CODE  FOR  OUNED  DATA  LISTS 

C  KRKDR-THE  INDIVIDUAL  RANKING  CODE  FOR  OUNED  DIRECTORIES. 

C  X0DE5-CDNTR0L  UORD  FIVE  FOR  DIRECTORIES 

C 


SUBROUTINE  RHDRD (NDB, LABEL, IDRAA, IERR , * , *) 

C — MODULE:  MCPABS/DBCS 
C—REFERENCE:  MOPADS  VOLUME  5.13 
C—  PURPOSE: 

C  RNDRD  WILL  RENAME  A  DIRECTORY 
C 

C  —  INPUT  PARAMETERS: 

C  NDB-DATA  BASEd-UORKING, 2-REFERENCE) 

C  LABEL-THE  NEU  LAiEL  FOR  THE  DIRECTORY (CHARACTER). 

C  DIRECTORY  LABELS  MAY  HAVE  40  CHARACTERS. 

C  IF  LABEL*  ,  MUNLABELEB)  MILL  BE  USED. 


C— INPUT/OUTPUT  PARAMETERS* 

C  IDRAA(4)-DRAA  OF  THE  DIRECTOR* 

C— OUTPUT  PARAMETERS? 

C  IERR-ERROR  CODE 

C  O-HO  ERROR 

C--ALTERMATE  RETURNS? 

C  l-IDRAA  NOT  ,'OUND 

C  2-IERR.NE.O 


SUBROUTINE  RRD(NPB,IDBA,ICP,DPf IERR , ♦ > 

C — MODULES  HOPADS/DBCS 
C— REFERENCE*  MOPADS  VOLUME  5.13 
C— PURPOSE* 

C  TO  READ  A  REAL  RECORD  FROM  A  DB 

C— INPUT  PARAMETERS* 

C  NDB-DBM-UORKING,  2-REF) 

C  1DBA~DBA(REC0RD  NUMBER) 

C— OUTPUT  PARAMETERS: 

C  ICP<NWCPD)-ARRAT  FOR  CONTROL  PART  OF  RECORD 

C  DP(NUDPD)-ARRAT  FOR  THE  DATA  PART  OF  THE  RECORD 

C  IERR-FRROR  CODE 

C  O-NO  ERROR 

C  1 ,2,3004,4002,4004,4005 

C— ALTERNATE  RETURNS* 

C  1-IERR.NE.O 


SUBROUTINE  RWRCDf IRU, IFMT , IFILE,INC, IDBAA, IERR,*) 

C— MODULE*  HOPADS/DBCS 
C— REFERENCE*  MOPADS  VOLUME  5.13 
C— PURPOSE* 

C  RURCD  WILL  READ/URITE  A  RECORD  FROM/ TO  A  SEQUENTIAL  INTERNAL 
C  FORMAT  OR  A  SEQUENTIAL,  EXTERNAL  FORMAT  FILE. 

C 

C — INPUT  PARAMETERS* 

C  IRU-READ/URITE  FLAG 

C  1-READ 

C  2-WRITE 

C  IFHT-FILE  FORMAT 

C  1-SEQUENTIAL  INTERNAL 

C  2-SEQUENTIAL  EXTERNAL 

C  IFILE -LOGICAL  UNIT  NUMBER  OF  THE  FILE 

C — INPUT/OUTPUT  PARAMETERS* 

C  JNC-TTPEU -NUMERIC, 2-CHARACTER) 

C  IRW»1  -ON  OUTPUT,  INC  IS  THE  COLUMN  NUMBER  OF  IBBAA 

C  THAT  CONTAINS  THE  DBAA  OF  THE  RECORD. 

C  IRU*2  -ON  INPUT,  INC  IS  THE  COLUMN  NUMBER  OF  IBBAA 

C  THAT  CONTAINS  THE  RECORD. 
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IDBAA( 2,2) -CURRENT  D8AA  FOR  THE  RECORD.  COLUMN  1  CONTAINS 

A  NUMERIC  DBCSA  AND  COLUftN  2  CONTAINS  A  CHARACTER 
DBCSA. 

1RU=1-0N  INPUT  1DBAA12,-)  IS  THE  DBCSA  FOR  THE  RECORD. 
ON  OUTPUT,  IDBAAd ,-)  IS  THE  CORRECT  RECORD 
NUMBER.  IN  OTHER  UQRDS,  RURCD  READS  THE  NEXT 
RECORD  ON  THE  FILE  INTO  CORE  SPACE  AT  I D 8 A A < 2 , — > 
AND  RETURNS  THE  RECORD  NUMBER  OF  THE  RECORD  IN 
IBBAAO  r-). 

1RUS2-IDBAA  IS  NOT  CHANGED  BY  RURCD 
—OUTPUT  PARAMETERS! 

IERR-ERROR  CODE 
0-N0  ERROR 

1 1-1DEAA  NOT  CURRENT  FOR  1RU=2 
3004-SYSTEM  ERROR  ON  IF1LE . 

— ALTERNATE  RETURNS! 

1-IERR.NE.O 


SUBROUTINE  R1D(NDB,NCREC,NUCP,NCDP,HXR,MAXR,ALPH,i'.LDi.ft, 
HHDLA,TDLA,NUAD,KARL1,IERK,IOERR,*) 

— MODULE:  MOPADS/DBCS 
-REFERENCE:  MOPADS  VOLUME  5.13 
— PURPOSE: 

TO  READ  RECORD  1  OF  A  DBF 
—INPUT  PARAMETERS: 

NDB-DBd-UORKIKG,  2-REF) 

OUTPUT  PARAMETERS: 

NCREC-NURECDd) 

NUCP-NUCPD 
NCDP-NCDPD 
HXR-MXRDd ,NDB) 

HAXRD-MXRD(2,NBB) 

ALPH-ALPHD 
MLDLA-MLDLAD 
MHDLA-MHDLAB 
TBLA-TDLAD 
NUAD-NUADD 
KARLI-KARLDd  ,ND) 

IERR-ERROR  CODE 
C  O-NO  ERROR 

C  3004 

C  IOERR-SYSTEM  ERROR  CODE 

C— ALTERNATE  RETURNS: 

C  1-IERR.NE.O 


SUBROUTINE  SAFD(SAFQLD,TSLU,ACCN,SAFNEU> 

C~ MODULE:  MOPADS/DBCS 
C— REFERENCE:  HOPADS  OLUNE  5.13 
C— PURPOSE: 

C  SAFD  COMPUTES  THE  NEU  ESTIMATE  OF  THE  SAF  FROM  THE  OLD. 

C— INPUT  PARAMETERS: 

C  SAFOLD-THE  LAST  ESTIMATE  OF  SAF 

C  TSLU-THE  VALUE  OF  TDLAD  UKEN  SAFOLD  UAS  COMPUTED. 

C  ACCN-NUMBER  OF  ACCESSES  OF  THIS  RECORD  SINCE  SAFOLB 

C  UAS  COMPUTED. 

C— OUTPUT  PARAMETERS: 

C  SAFNEU-THE  NEU  ESTIMATE  OF  SAF 


SUBROUTINE  SAFID(IOPT) 

C--MOBULE:  MOPADS/DBCS 
C— REFERENCE:  MOPADS  VOLUME  3.13 
C-- PURPOSE: 

C  SAFI D  PERFORMS  AN  IN-COPE  UPDATE  ON  THE  SAF  DATA 

C  IN  THE  US  AND  TS.  SAF1D  DOES  NOT  SCHEDULE  THE 

C  NEXT  PERIODIC  UPDATE. 

C — INPUT  PARAMETERS: 

C  IOPT-OPTION 

C  1-DO  NOT  SUAP  RECORDS  FROM  THE  TS  TO  THE  US  TO  GET 

C  HIGHEST  SAF'S  IN  US. 

C  2-AFTER  UPDATE,  SUAP  RECORDS  TO  US  JF  NEEDED  TO  GET 

C  HIGHEST  SAF'S  IN  WSUORKING  DATA  BASE  OHLT). 


SUBROUTINE  SAF2D(NDB,IDBCS,ITYP,IERR,*) 

C— MODULE:  MOPADS/DBCS 
C-REFERF.NCE:  HOPADS  VOLUME  5.13 
C— PURPOSE: 

C  SAF2D  READS  A  RECORD  AND  UPDATES  THE  SAF  DATA. 

C  SAF2D  DOES  NOT  CHANGE  THE  IN-CORE  LINKING  DATA. 

C— INPUT  PARAMETERS: 

C  NDB-DATA  BASE1 1 -UORKING, 2-REFERENCE) 

C  IDBCS(2)-BBAA  OF  THE  RECORD. 

C  ITTP-DL  TYPE 

C  1 -NUMERIC 

C  2-CHARACTER 

C — OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  O-KO  ERROR 

C  3004,4002 

C— ALTERNATE  RETURNS: 

C  1 -IERR.NE.0 
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SUBROUTINE  SAF3D t NUB , IOPT , IOBC , I T TP, 

C — NODULE:  HGPADS/DBCS 
C~ REFERENCE:  HOPADS  VOLUME  5.13 
C— PURPOSE: 

C  TO  UPDATE  THE  SAP  OF  A  DL  OR  DR  PECORD  PRIOR  70  URI TING 

C  IT  TO  DISK.  SAF3D  WRITES  THE  RECORD,  AND  OPTIONALLY  DELINKS 

C  IT  FROM  THE  IN-CORE  DATA  STORE  AND  HAKES  THE  SPACE  AVAILABLE 

C  IN  THE  TS  OR  US. 

C — INPUT  PARAMETERS: 

C  NDB-DATA  BASE! 1 -WORKING, 2-REFERENCE) 

C  IOPT-OPTION 

C  1-UPDATE  AND  WRITE  TO  DISK 

C  2-UPDATE, URITE  TO  DISK,  AND  DELINK  RECORD 

C  IDBC-DBCSA  OF  THE  RECORD  TO  BE  WRITTEN. 

C  ITYP-DL  TYPE 

C  1 -NUMERIC 

C  2-CHARACTER 

C— OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  3004 

C— ALTERNATE  RETURNS: 

C  1-IERR.NE.O 


Sl’TROUTINE  SETDSDiKNTSD,NNCTSB,lERR, *) 

C— MODULE:  HOPADS/DBCS 
C— REFERENCE:  HQPADS  VOLUME  5.13 
C— PURPOSE: 

C  SETDSD  SETS  THE  BREAK  POINTS  OF  I HE  DATA  STORE 
C 

C— INPUT  PARAMETER: 

C  NNTSC-NUHBtf.  OF  RECORDS  FOR  THE  NUMERIC  TSUF  .LE.  0,  USE 
C  THE  CURRENT  VALUE) 

C  NNCTSD-NUMBER  OF  RECORDS  FOR  THE  CHARACTER  TS<IF  .LE.O,  USE 

C  THE  CURRENT  VALUE) 

C— OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  4001-INSUFFICIENT  DATA  STORE  SPACE 

C— ALTERNATE  RETURNS: 

C  1-IERR.NE.O 
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SUBROUTINE  SHFDRD(N3B,IC1 ,IC2,NC, IDIR,IDB0,1ERR,*) 

C--NODULE:  HOFADS/DBCS 
C—REFtRENCE:  HOPAKS  VOLUME  5.13 
C-PURPPSE: 

C  SHFKRB  IS  A  UTILITY  PROGRAM  WHICH  UILL  SHIFT  COLUMNS  OF 

C  A  DIRECTORY  TO  OPEN  UP  SPACE  FOR  INSERTION.  IT  UILL 

C  SHIFT  COLUMNS  IC1  THRU  IC2  NC  COLUMNS  IN  THE  DIRECTION 
C  IDIR.  NOTE:  NO  CHECK  IS  HADE  TO  INSURE  THAT  DATA  IS  NOT 
C  DESTROYED  BY  THE  OPERATION.  THE  CURRENT  POSITIONS  OF  THE 

C  DIRECTORY  ARE  UPDATED  IF  NECESSARY.  SHFDRD  IS  CALLED  ONLY 

C  BY  INSDRD. 

C— INPUT  PARAHETERS: 

C  1  NDB-DATA  BASE1 1 -WORKING, 2-REFERENCE > 

C  I  1C1 , IC2-COLUMNS  TO  SHIFT.  If  THE  COLUMNS  ARE  INVALID,  RETURN 

C  WITH  NO  ACTION 

C|,'  NC-THE  NUMBER  COLUMN  POSITIONS  TO  SHIFT. 

C  |  IDIR-DIRECTIOM 
C  1-FORUARDC AWAY  FORM  ONE) 

C  2-BACKWARD ^TOWARD  ONE) 

L  — INPUT/OUTPUT  PARAHETERS: 

C  IDBO( 4)-DRAA  OF  THE  DIRECTORY.  IT  MUST  BE  CURRENT 

C— OUTPUT  PARAHETERS: 

C  IERR-ERROR  CODE 

C  O-HO  ERROR 

C— ALTERNATE  RETURNS: 

C  1-IERR.NE.O 


f 

SUBROUTINE  SHRTND(NDB,NELCR, IDBAA,IERR,*) 

C— MODULE:  HOPADS/DBCS 
C--REFERENCE:  MOPADS  VOLUME  5.13 
C— PURPOSE: 

C  '  TO  SHORTEN  A  DL  OR  DR 
c4lNPUT  PARAHETERS: 

C  NDB-DATA  BASEd-WORKIN' ,2-REFERENCE) 

C  NELCR-TrlE  LAST  DESIRE  ELEMENT  OF  THE  DL  OR  DR. 

C  ALL  ELEMENTS  <FTER  NElCR  WILL  BE  DELETED1 IRREVOCABLY) , 

C  IF  NELCR. U.O,  THE  ENTIRE  DL  OR  DR  CHAIN  WILL  BE 

C  DELETED.  IF  NELCR  IS  BEYOND  THE  END  OF  THE  DL  OR  DR, 

C  RETURN  WITH  NO  ACTION.  NELCR  HAS  DIFFERENT  HEARINGS 

C  FOR  EACH  TYPE  OF  DL. 

C  1.  A  1-DIMENSIONAL  DL  —NELCR  IS  AN  ELEMENT  NUMBER. 

C  2.  A  COLUMN  ORIENTED  DL  OR 

C  A  DIRECTORY  —NELCR  IS  THE  LAST  DESIRED  COLUMN 

C  !lO  RETAIN. 

C  3.  A  ROW  ORIENTED  DL  —NELCR  IS  THE  LAST  ROW  TO 

C  RETAIN. 
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C--INPUT/QU7PUT  PARAMETERS: 

C  I0BAA(2)-A  DBAA  FOR  THE  DL  OK  OR.  ON  RETURN  JT  U1U  BE  THE 
C  CURRENT  DBAA  Of  THE  RECORD  CONTAINING  NELCR. 

C 

C — OUTPUT  PARAMETERS: 

C  1ERR-ERROR  CODE 

C  O-NO  ERROR 

C  1 ,2,4,8, OTHERS 

C— ALTERNATE  RETURNS: 

C  1-IERR.NE.O 


SUBROUTINE  SRDSD ( NDB , I T YP , I  OFF , MATCH , NOT  I , LOCN ) 

C — MODULE:  HOPADS/DBCS 
C— REFERENCE:  MOPADS  VOLUME  5.13 
C — PURPOSE: 

C  SRDSD  SEARCHES  THE  DATA  STORE  FOR  AN  ENTRY 

C  EQUAL  TO  NATCH  THAT  IS  IN  THE  SAME  DATA  BASE.  IT  LOOKS  FOR 

C  IABS(KSTDRD( I+IOFF ) )=HATCH,  UHERE  I  IS 

C  THE  DBCSA  OF  THE  RECORD 

C — INPUT  PARAMETERS: 

C  NDB-DATA  BASE «1 -UORKING, 2-REFERENCE) 

C  ITYP-TYPE( 1 -NUMERIC, 2-CHARACTER ) 

C  IOFF*OFFEET  FROM  THE  1ST  UQRD  OF  THE 

C  CONTROL  PART 

C  NATCH-ELEMENT  TO  FIND 

C  NOTI-SRDSD  UIL'.  IGNORE  A  RECORD  UITH  DBCSA^NOTl  EVEN 

C  IF  IT  MATCHES.  THIS  PERMITS  A  RECORD  TO  SEARCH 

C  FOR  ANOTHER  RECORD  OF  THE  SAME  CHAIN  UITHOUT  FINDING 

C  ITSELF. 

C— OUTPUT  PARAMETERS: 

C  LOCN-THE  DBCSA  OF  THE  RECORD  UHOSE  IOFF-TH 

C  UORD=MATCH. 

C  ZERO  IF  NONE. 


SUBROUTINE  SUP6D ( IONOFF ) 

C— MODULE:  MOPADS/DECS 
C — REFERENCE:  MOPADS  VOLUME  5.13 
C— PURPOSE: 

C  SUP4D  UILL  SUPPRESS  DECS  ERROR  6.  SOME  INTERNAL  DBCS  PROGRAMS 

C  DELIBERATELY  READ  PAST  THE  END  OF  A  DL  OR  DR.  THESE  OCCUPRANCES 

ARE  NOT  REPORTED  AS  ERRORS  BY  USING  SUP6P  TO  ELIMINATE  THE 
ERROR  MESSAGE. 

C  —  INPUT  PARAMETERS: 


C  I ONGFF -SUPPRESS I (H  SUITCIi 

C  1 -TURK  ERROR  6  REPORTING  ON 

C  2-TURN  ERROR  6  REPORTING  OFF 


SUBROUTINE  SUAPDUTYP, ICURK, ID73,IDUS) 

C — MODULE:  MOPADS/DBCS 
C — REFERENCE;  MOPADS  VOLUME  5.13 
C— PURPOSE: 

C  SUAPD  SUAPS  A  RECORD  FROM  THE  TS  TO  THE  US.  IT  DOES 

C  NOT  EXAMINE  THE  US  TO  UPDATE  SAFMND  OR  MNDSFD. 

C  BOTH  RECORDS  REMAIN  LINKED  PROPERLY  IN  THE  DATA  STORE. 

C— INPUT  PARAMETERS: 

C  I7YP-TYPE(1-NUrtERIC, 2-NUMERIC) 

C  ICURK(2)-DBCSA'S  OF  ONE  RECORD  OF  SPACE  IN  THE  IS. 

C  (D-CONTROL  PART, <2)-DATA  PART' 

C--INPUT/OUTPUT  PARAMETERS : 

C  IDTS-< INPUT )-DBC3A  OF  THE  TS  RECORD 

C  (OUTPUT)-DBCSA  OF  THE  SAME  RECORD  NOU  IN  THE  US. 

C  IDUS-(INPUT)-DBCSA  OF  THE  US  RECORD 

C  (OUTPUT)-DBCSA  OF  THE  SAME  RECORD  IN  THE  TS 


SUBROUTINE  ULKDSD(IDBCS,LSTR> 

C--MODULE:  MOPADS/DBCS 
C — REFERENCE :  MOPADS  VOLUME  5.13 
C — PURPOSE: 

C  ULKDSD  UILL  UNLINK  A  RECORD  FROM  THE  DATA  STORE 

C  AND,  IF  NECESSARY,  LINK  THE 

C  FREED  UP  SPACE  TO  THE  AVAILABLE  SPACE  IN  THE  US. 

C  THE  RECORD  NUMBER  IS  SET  TO  ZERO  ALSO.  ULKDSD 

C  ASSUMES  ANY  INFORMATION  IN  THE  RECORD  IS  NOT 

C  USEFUL,  SINCE  IT  MAT  NOT  BE  ACCESSIBLE  AFTER 

C  RETURN. 

C — INPUT  PARAMETERS: 

C  IDBCS-DBCSA  OF  THE  RECORD  TO  BE  UNLINKED. 

C  IF  IDBCS.LE.O,  RETURN  UITH  NO  ACTION 

C  LSTR-  STORAGE  PQSITIONUE  LSTR=LS7QR<K IDBCS ) ) 

r.  IF  LSTR  .LE.  0,  ULKDSD  UILL  CALL  LSTORD. 


SUBROUTINE  UPDATD1NDB.IERR,*) 
C— MODULE:  MOPADS/DBCS 
C— REFERENCE:  MOPADS  VOLUME  5.13 
C— PURPOSE: 
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C  TO  UPDATE  THE  DBF  ON  DISK  SO  IT  IS  THE  SAME  AS  IN-CORE. 

C  IF  THE  DB  IS  NOT  OPEN  OR  IS  READ-ONLY,  RETURN  UITH  NO 

C  ACTION. 

C— INPUT  PARAMETERS: 

C  NDB-DATA  BASE 

C  O-BOTH 

C  1 —WORKING 

C  2-REFERENCE 

C — OUTPUT  PARAMETERS! 

C  I ERR-ERROR  CODE 

C  O-NO  ERROR 

C  .NE.O-I/O  ERRORS  ON  DB 

C — ALTERNATE  RETURNS: 

C  1 -IERR.NE.0 


SUBROUTINE  UC1XNDB, ICP,CDP,IERR,*) 

C— NODULE:  MOPADS/DTCS 
C—REFERENCE:  NOPADS  VOLUME  5.13 
C — PURPOSE: 

C  TO  URITE  A  CHARACTER  RECORD  TO  THE  DBF 
C 

C — INPUT  PARAMETERS: 

C  NDB-DATA  BASE ( 1 -WORKING ,2-REFERENCE) 

C  ICPlNUCPD)  THE  CONTROL  PART  OF  THE  RECORD 

C  CDP*NCDPD-THE  DATA  PART  OF  THE  RECORD (CHARACTER) 

C— OUTPUT  PARAMETERS: 

C  IERR-ERP.OR  CODE 

C  O-NO  ERROR 

C  1,2,3004, *004,4005 

C— ALTERNATE  RETURNS: 

C  1 -IERR.NE.0 

C 


SUBROUTINE  UD(ND£,IDBAR,IERR,*> 

C— MODULE:  MOPADS/DBCS 
C  —  REFERENCE:  MOPADS  VOLUME  5.13 
C— PURPOSE: 

C  UD  URITES  A  RECORD  TO  THE  DB 

C  — INPUT  PARAMETERS: 

C  NDB-DB(1 -WORKING, 2-REF) 

C  IPBAR(2)-DBCSA'S  OF  CONTROL  AND  DATA  PARTS, RESPECTIVELY 
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-OUTPUT  PARAMETERS: 

IERR-ERROR  CODE 
O-NO  ERROR 
-ALTERNATE  RETURNS: 

1-IERR.NE.O 


SUBROUTINE  UID<NDB,ICP,IDP,I£RR,*) 
-MODULE:  MOPADS/DBCS 
-REFERENCE:  MOPADS  VOLUME  5.13 
-PURPOSE: 

TO  URITE  A  INTEGER  RECORD  TO  THE  DBF 


-INPUT  PARAMETERS: 

NDB-DAT A  BASE<1-U0RK1NG, 2-REFERENCE) 
ICP(NUCPD)  THE  CONTROL  PART  OF  THE  RECORD 
IDP(NUDPD)-THE  DATA  PART  OF  THE  RECORD 
-1UTFJT  PARAMETERS: 

IERR-ERROR  CODE 
O-NO  ERROR 
1 ,2,3004,4004 ,4005 
-ALTERNATE  RETURNS: 

1-IERR.NE.O 


SUBROUTINE  URD1NDB, ICP , RDP, IERR, * ) 
-MODULE:  MOPADS/DBCS 
-REFERENCE:  MOPADS  VOLUME  J. 13 
-PURPOSE: 

TO  URITE  A  REAL  RECORD  TO  THE  DBF 


-INPUT  PARAMETERS: 

NDB-BATA  BASE ( 1 -UGRKING, 2-REFERENCE) 
ICP1NUCPD)  THE  CONTROL  PART  OF  THE  RECORD 
RDP(NUDPB)-THE  DATA  PART  OF  THE  RECORD 
-OUTPUT  PARAMETERS: 

IERR-ERROR  CODE 
O-NO  ERROR 
1,2,3004, 400-1,4005 
-ALTERNATE  RETURNS: 

1-IERR.NE.O 
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SUBRuUTTNI  UiD(NDB,IERR,IQERR,*) 

C~ MODULE:  .-OPADS/PBCS 

C~ R£Ft:,ENCE:  NOPADS  VOLUME  5.13 

C—PURPL'E: 

C  ti>  WRITE  THE  FIRST  RECORD  TO  A  DBF 

C--1MPUT  PARAMETERS: 

C  HUB-DATA  BAS£( 1 -WORKING, 2-REFERENCE) 

C— OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  O-NO  ERR 

C  1 ,2,3004 

C  XOEKR-SYSTEtt  I/O  ERROR  CODE 

C  O-HO  ERROR 

C  .NE. O-SYSTEM  ASSIGNED  ERRJR  ODE 

C— ALTERNATE  RETURNS: 

C  1-IERR.Nt.O 

C 


SUBROUTINE  W2RUD( IRU, IFMT,IFILE,LD8F, 1ERR,*) 

C— MODULE:  MCPADS/DBCS 
C— REFERENCE:  MOPADS  VOLUME  5.13 
C— PURPOSE: 

C  U2RUD  UILL  : 

C  1.  READ  SEQUENTIAL  INTERNAL/EXTERNAL  FORMATTED  DBF'S  TO 

C  AN  EMPTY  DIRECT  ACCESS  DBF. 

C  2.  WRITE  A  DIRECT  ACCESS  DBF  TO  A  SEQUENTIAL  INTERNAL 

C  OR  EXTERNAL  FORMAT  FILE. 

C  NO  REFERENCE  DATA  BASE  MAY  BE  OPEN  DURING  YHIS  OPERATION. 

C — INPUT  PARAMETERS: 

C  IRW-READ/URITE  FLAG 

C  1-READ  SEQUENTIAL  FILE  AND  WRITE  TO  A  DIRECT  ACCESS  DBF 

C  2-READ  DIRECT  ACCESS  DBF  AND  WRITE  TO  A  SEQUENTIAL  FILE 

C  IFMT-SEOUENTIAL  FILE  FORMAT 

C  1 -SEQUENTIAL  INTERNAL  (UNFORMATTED)  FILE 

C  2-SEQUENTIAL  EXTERNAL  (FORMATTED)  TILE 

C  IFILE-IOGICAL  UNIT  NUMBER  OF  THE  SEQUENTIAL  FILE.  THE  DBCS  DOES  N 

C  OPEN,  CLOSE,  OR  REWIND  THIS  FILE.  IF  IRW=2,  AN  ENDFILE  UILL 

C  BE  EXECUTED  ON  ...IS  FILE  AFTER  THE  DB  IS  WRITTEN  TO  IT. 

C  LDBF-(CHARACTER)  THE  NAME  OF  THE  DIRECT  ACCESS  DB  FILE.  U2RUD  UIL 

C  OPEN  THIS  FILE  AND  CLOSE  IT  WHEN  DONE.  LDBF  SHOULD  NOT  BE 

C  CONCURRENTLY  OPEN  AS  THE  WORKING  OR  REFERENCE  DB. 

C — OUTPUT  PARAMETERS: 

C  IER3-ERR0R  CODE 

C  O-NO  ERROR 

C  .NE.O-DBCS  ERROR.  POSITION  PF  FILE  IFILE  IS  UNPREDICTABLE. 

C— ALTERNATE  RETURNS: 

C  1-IERR.NE.O 
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VI.  USER  INSTRUCTIONS 


1- 0  ACCESS  ADDRESSES. 

The  primary  means  of  accessing  information  with  tae  DECS 
is  through  access  addresses.  There  are  two  types:  Data  Base 
Access  Addresses  (IBAA's)  for  data  lists  and  Directory  Access 
Addresses  (DRAA's)  for  directories.  DBAA's  consist  of  two  words, 
and  DRAA's  consist  of  four  words.  See  Table  VI-1.  The  user's 
application  program  need  never  be  concerned  about  the  contents 
of  the  DBAA's  and  DRAA's.  It  must  simply  provide  storage  to  hold 
the  addressing  information. 

The  normal  accessing  method  is  as  follows:  The  application 
program  requests  the  DECS  to  locate  a  data  list  or  directory  (the 
ways  this  can  be  done  are  explained  below).  The  DECS  locates  it 
and  returns  its  DBAA  (or  DRAA)  in  an  array  the  user  has  provided. 

What  the  DECS  has  done  is  bring  at  least  one  record  of  the  DL 
(or  DR)  into  core  and  store  its  DBA  (or  its  negative  if  it  is  a 
character  record)  in  word  one  of  the  DBAA  (DRAA).  Word  two  con¬ 
tains  its  current  DECS  A.  For  directories,  words  3  and  U  are  also 
set  to  zero  (this  essentially  sets  the  current  directory  positions 
to  the  beginning). 

Now,  whenever  the  application  program  desires  to  access  that 
DL  (or  DR),  it  passes  the  DBAA  (DRAA)  to  the  DBCS  which  is  able  to 
■*  quickly  locate  the  information  'a.  core  or  to  determine  that  addi¬ 

tional  records  must  be  read  from  disk.  As  discussed  previously, 
all  record  management  is  performed  internally  by  the  DBCS.  The  DBCS 
also  updates  elements  of  the  DBAA's  (and  DRAA's)  as  needed. 

The  DBAA  and  DRAA  are  the  primary  means  by  which  the  DBCS 
avoids  frequent  DB  searches  for  information.  Conventional  hierarchical 
searches  for  a  DL  or  DR  can  be  performed  once  (these  are  slow),  and 
then  the  DBAA  or  DRAA  pan  be  used  on  all  subsequent  accesses  of  that 
data  (these  are  fast).  The  user  program  must  "remember"  DBAA's  and/ 
or  DRAA’s  for  each  DL  or  DR  which  is  frequently  accessed  in  order  to 
take  advantage  of  this  efficient  addressing. 

2- 0  USING  THE  DBCS. 

2-1.  Initializing  the  DBCS. 

Subroutine  INITD  must  be  called  prior  to  calling  any  other 
DBCS  programs.  Rote  that  BLOCK  DATA  program  BLOCKD  must  be  loaded 
with  the  DBCS  also. 
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Table  VI-1.  Contends  of  Data  Base  and  Directory  Access  Addresses 
(DBAA  and  DRAA). 


Word 

DBAA 

DRAA 

1 

The  DBA  of  the  last  record 
of  the  CL  accessed.  Word 

1  will  he  negative  for 
character  DL's. 

Same  as  for  DBAA  but 

DR's. 

2 

DBCSA  of  the  record  speci¬ 
fied  in  Word  1. 

Same  as  for  DBAA. 

3 

Hot  applicable. 

Current  directory  position 
for  directories  of  the  DR. 

h 

Not  applicable. 

Current  directory  position 
for  data  lists  of  the  DR. 

2-2.  Opening/Closing  DB's. 

Use  Subroutine  OPNDBD  to  open  DB  files.  MAXR  is  a  parameter 
needed  on  some  computer  systems  which  require  that  the  maximum  size  of 
the  file  be  specified  at  creation  time. 

Use  Subroutine  CLSDBD  to  close  a  DB.  If  ISTAT  is  specified  as  2, 
the  DBF  will  be  deieted(i.e. ,  lost  forever)  after  the  file  is  closed. 

DBF’s  may  be  opened  and/or  closed  as  often  as  needed  during  a 
DBCS  job. 


2-3.  Creating  Directories. 

Two  subprogram  calls  are  required  to  create  a  directory. 

The  first  is  a  call  to  Subroutine  CTRDRD.  CRDRD  creates  an  empty  direc¬ 
tory  that  is  not  owned  ny  another  directory.  It  also  returns  the  DRAA 
of  the  new  directory.  Subroutine  IRSDRD  is  used  to  "insert"  the  new 
directory  into  another  directory.  In  other  words,  after  calling  INSDRD, 
the  new  directory  is  owned  by  another  directory. 
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LNSDRP  requires  knowledge  of  the  FRA.A  of  the  owning  directory. 
This  is  no  problem  except  for  the  master  directory.  When  inserting 
directories  (or  data  lists)  in  the  master  directory,  it  is  necessary 
to  know  the  master  directory’s  DRAA.  This  case  is  the  only  instance 
in  which  an  application  program  must  be  aware  of  internal  DBCS 
variables.  The  array  1SYDBD  (see  Section  VIII)  always  contains  the 
DRAA  of  the  master  directory.  The  user  application  program  zrist  have 
COMMON /DB CS 3D/  to  gain  access  to  this  array.  The  recommended  pro¬ 
cedure  is  to  minimize  the  number  of  application  program  subprograms 
which  must  access  this  COMMON  area. 

2-1* .  Creating  Data  List 3. 

Creating  data  lists  is  similar  to  creating  directories. 
Two  subprogram  calls  are  required.  The  first  is  to  Subroutine  CRDLD 
to  create  the  DL,  and  the  second  is  to  Subroutine  INSDRD  to  insert 
the  new  DL  in  its  proper  place  in  the  owning  direcotry.  Creating 
DL's  to  be  owned  by  the  master  directory  require  access  to  the  array 
ISYn3D  as  explained  in  Section  2-3  above. 

The  data  lists  created  by  this  procedure  are  empty.  In  other 
words,  they  contain  no  elements.  Populating  a  data  list  is  dis¬ 
cussed  next. 


2-5.  Storing  and  Retrieving  Information  From  a  Data  List. 

There  are  18  subprograms  for  storing  and  retrieving 
elements  of  data  lists  which  will  be  described  shortly.  When  an 
application  program  nstructs  that  data  be  stored  in  an  element  that 
is  beyond  the  current  length  of  the  data  list,  the  DL  is  extended  and 
the  data  is  stored.  All  intervening  elements  are  also  created  and 
are  assigned  values  of  zero  for  numeric  DL's  or  blank  for  character 
DL's.  For  example,  if  a  user  assigns  a  value  ol  15  to  element  12  of 
a  new  DL  (which  currently  has  no  elements),  then  element  12  will 
equal  15  end  elements  1  through  11  will  exist  and  equal  zero. 

If  a  user  program  requests  the  value  of  an  element  that  is 
beyond  the  current  length  of  a  DL,  an  error  results  (see  DBCS  error 
6  in  Section  VII). 
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The  subprograms  for  storing  tad  retrieving  DL  element 8  arc 
shovn  below. 
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These  sub  *ontinesi  p-rt  information  into  DL's 
of  type  *diaracter  (C),  integer  (I),  and 
real  (Ph 


These  subroutines  retrieve  (get)  .inforsa* 
tion  from  DL's  analogous  to  PCD,  PJD,  and  . 
PRD  above. 


prow  j 1  v  a 


These  subroutines  put  information  into  a  row 
of  a  two-dimensional  DL.  See  the  note  below. 
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These  subroutines  retrieve  information  from 
a  row  of  a  two-dimensional  DL.  See  the  note 
below. 


These  subroutines  put  information  into  a 
column  of  a  tvo-direasional  DL.  See  the 
note  below. 


GCOL  j  I|  D 


These  subroutines  retrieve  information  from  a 
row  of  a  two-dimensional  DL.  See  the  note 
below. 


Recall  that  character  DL's  can  be  one¬ 
dimensional  only.  Therefore,  Subroutines  PROWCD, 
GROWCD,  PCOLCD,  and  GCOLCD  are  non-functional. 
They  are  included  only  to  allow  for  future  modi¬ 
fications  to  the  DBCS. 


n 


With  each  of  these  subprograms,  the  user  program  passes  in  an 
array  to  hold  the  values  of  the  DL.  If  the  operation  is  to  retrieve 
data,  the  DBCS  copies  the  specified  values  to  this  array.  If  the 
operation  is  to  store  data  tc  the  DL,  the  DBCS  copies  the  new  values 
from  the  user  array  into  the  DL.  This  effectively  overwrites  the 
previous  values  of  the  elements  that  were  stored  in  the  DL. 

When  storing  and  retrieving  data  from  two-dimensional  DL's, 
the  user  need  not  be  concerned  as  to  whether  the  DL  is  row  or  column 
oriented.  The  DBCS  accounts  for  this  internally.  It  is,  however, 
more  efficient  to  access  row  oriented  DL's  by  rows  and  column 
oriented  DL's  by  columns.  In  other  words,  it  is  more  efficient  to 
use  PP.OW-D  and  GROW-D  with  a  row  oriented  DL.  This  implies  that 
during  design  of  the  data  base,  DL's  that  will  be  accessed  most, 
frequently  by  rows,  for  example,  should  be  row  oriented. 

2-6.  Assigning  and  Accessing  Labels  of  Data  Lists  and 
Data  List  Elements. 

To  give  a  data  list  a  label,  use  Subroutine  PLBDLD. 
PLBDLD  will  overwrite  a  previous  label.  If  no  label  has  been 
assigned  to  a  DL,  it  has  a  default  label  of  "(UNLABLED)". 


N 


Subroutine  PLBELD  is  used  to  assign  labels  to  elements  of 
DL's.  In  this  case  an  array  of  lab  e'  «t  is  .passed  to  PLBELD  for 
assignment  to  specified  elements.  Every  element  of  a  DL  may  be 
assigned  a  labe] ,  even  every  element  of  a  two-dimensional  DL-  DL 
elements  which  have  no  assigned  labels  are  given  default  labels  of 
"( UNLABELED )".  Recall  that  all  DL  and  DL  element  labels  have  25 
or  less  characters. 

Subroutine  GLBDLD  will  return  the  label  of  a  DL  given  its 
DBAA.  Similarly,  Subroutine  GLBELD  will  return  labels  of  speci¬ 
fied  elements  of  a  DL  given  the  DL's  DBAA.  If  the  user  program 
requests  labels  beyond  the  end  of  the  LDL  (in  other  words,  the  LDL 
is  shorter  than  its  parent  DL  so  some  DL  elements  have  no  assigned 
labels),  GLBELD  will  return  labels  of  "(UNLABELED)"  for  the  missing 
elements,  and  it  will  also  generate  an  error  number  6  (see  Section 
VII). 

2-7.  Assigning  and  Accessing  Directory  Labels. 

Directory  labels  are  normally  assigned  when  the  DR  is 
created.  A  directory  may  be  renamed  by  using  Subroutine  RNDRD.  A 
DR's  label  can  be  accessed  with  Subroutine  GLBDRD.  Both  RNDRD  and 
GLBDRD  require  the  DR's  DRAA. 
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2-8.  Searching  a  Directo: 


It  is  sometimes  necessary  to  search  a  directory  for  a 
particular  DL  or  DR  that  is  owned  by  the  directory.  There  are 
several  facilities  in  the  LtBCS  for  doing  this. 

2. 8.  a.  Subroutine  FDBID  will  search  a  directory  for  an 
owned  DL  or  DR  with  a  specified  ID.  FDBID  returns  the  DBAA  or  DRAA 
of  the  found  DL  or  DR  and  sets  the  current  position  of  the  owing 

DR  to  the  found  entry. 

2.8. b.  Subrouting  CDLLBD  will  search  a  directory  for  an 
owned  DL  that  has  a  specified  label.  GDLLBD  returns  the  DL’s  DBAA 
and  sets  the  owning  DR's  current  DL  position  to  the  found  data  list. 

2.8. c.  Subroutine  NXD  provides  a  flexible  search  capa¬ 
bility  to  locate  owned  DL's  and  DR's.  The  important  feature  of  NXD 
is  that  the  search  criteria  are  specified  by  the  user.  NXD  allows 
searches  of  the  following  type: 


-  Find  the  next  DL  in  the  forward  direction  (away  from  the 
start  of  the  DR)  with 

-  the  first  ID  element,  IL(l),  equal  to  b,  and 

-  the  third  ID  element,  ID(3),  greater  than  6,  and 

-  the  fifth  ID  .lament,  ID(!5),  not  equal  to  1. 

NXD,  in  the  case  above,  would  begin  at-  the  current  DL  position  of  the 
DR  and  search  forward  for  a  DL  whose  ID  satisfies  the  specified  con¬ 
dition.  Similar  searches  can  be  performed  for  owned  Directories. 

NXD  returns  the  found  entity’s  ID,  and  DBAA  or  DRAA;  it  also 
sets  the  owning  DR's  current  DL  or  DR  position  to  the  found  entity. 

2.8.d.  Subroutine  POSDRD  can  be  used  with  NXD.  PCSDRD 
sets  the  current  DL  or  DR  position  of  a  directory  to  its  beginning 
or  end. 


2-9.  Locating  a  Directory  or  Data  List. 

2.9-a.  Subroutine  GDRL3D  will  return  the  DRAA  of  a  direc¬ 
tory  that  has  a  specified  label.  It  will  search  the  entire  data  base. 
If  directory  labels  are  not  unique,  GDKLED  will  return  the  DRAA  of  the 
first  directory  whose  label  matches  the  specified  label. 

2.9>b.  Subroutine  FIDLD  will  return  the  label  and  ID  of 
a  DL  or  DR  that  has  a  specified  DRAA. 


2-10.  Clearing  and  Deleting  Directories. 

2.10. a.  Subroutine  C1RDLD  will  delete  all  data  lists 
that  are  owned  by  a  specified  directory.  The  DL's  are  irrevocably 
lost. 


2.10.b.  Subroutine  CLRDRD  will  empty  a  directory  of 
all  of  its  contents.  All  owned  DL's  are  deleted  and  all  owned 
directories  with  all  of  thnlr  owned  entities,  etc.,  are  deleted. 
In  other  words,  CLRDRD  deletes  e^ery  thing  which  descends  from 
a  specified  directory. 


2.10. C.  Subroutine  DELDRD  will  delete  a  direccory. 

It  removes  the  ID  of  the  DR  from  its  owning  directory  and  deletes 
the  directory  itself.  A  directory  must  be  empty  before  it  can  be 
deleted,  so  the  user  program  must  explicitly  delete  all  owned  DL's 
and  DR's  or  use  Subroutine  CLRDRD  to  clear  the  directory  prior  to 
calling  DELDRD. 

2-11.  Shortening  and  Deleting  Data  Lists. 

2. 11.  a.  Subroutine  SHRTND  will  shorten  a  data  list. 

A  parameter,  NELCR,  is  passed  to  SHRTND  which  specifies  the  last 
element  to  retain.  For  one  dimensional  DL's,  the  NELCR  will  be 
the  last  element  of  the  data  list.  For  column  oriented  DL's, 

NELCR  will  be  the  last  column;  ail  subsequent  columns  will  be 
deleted.  Similarly,  for  row  oriented  DL's,  NELCR  is  the  last  row 
that  is  retained.  If  NELCR  -  0  for  any  case,  the  DL  is  emptied, 
but  it  is  not  deleted. 

2.11. b.  Subroutine  DELDLD  deletes  data  lists.  In 
addition  to  deleting  ail  elements  of  the  DL,  it  also  removes  its 
entry  from  its  owning  directory.  No  call  to  SHRTND  is  needed 
prior  to  calling  DELDLD. 

2-12.  Finding  the  Owner  Directory  and  Determining  If  a 

Data  Base  is  Open. 

2.12.  a.  Subroutine  PLINKD  will  return  the  DRAA  of  the 
owner  of  a  specified. directory  or  data  list.  The  programs  described 
in  Section  2-8  can  be  used  to  find  entities  owned  by  a  directory 
and  PLINKD  can  be  used  to  find  the  owner  of  a  DL  or  DR.  Thus,  it  is 
possible  to  search  up  and  down  the  data  base  links  for  information. 

2.12. b.  Subroutine  ASKD  will  return  an  indication  of 
whether  a  particular  D3  (working  or  reference)  is  open. 

2-13.  Finding  the  Current  Position  of  a  Directory. 

Subroutine  CURD  will  return  the  initial  DBA  and  ID  of 
the  current  DL  or  DR  position  of  a  directory.  If  the  initial  DBA 
of  the  current  position  is  stored  in  the  first  word  of  an  array  of 


length  two  (four  for  directories) iand  the  rest  of  the  arrey  is  zero 
filled,  then  the  array  may  he  used  as  a  DBAA  (DRAA)  for  the  entity 
at  the  current  position. 


It  is  possible  to  to  get  the  contents  of  a  directory  or  . 
data  list  printed  on  the  DBCS  output  file.  This  file  is  formatted 
with  standard  carriage  control  characters  so  it  can  be  listed  on  a 
line  printer. 

Subroutine  PRTDLD  will  print  all  or  part  of  a  data  list  on  the 
output  file.  Use  Subroutine  PRTDRD  to  print  the  contents  of  a  direc¬ 
tory.  Both  of  these  subprograms  allow  the  user  programs  to  specify 
a  message  to  be  printed  with  the  DB  information. 

2-15.  Set  and  Retrieve  DBCS  Options.  *  I  I 

Subroutine  DBOFTD  allows  the  user  program  to  set  (and 
retrieve  the  settings)  of  17  options  for  the  DBCS.  Many  of  the 
options  are  self  explanatory  from  the  comments  in  Section  V  for 
Subroutine  DBOFTD.  Same  options  require  explanations,  however; 
these  options  are  discussed  here. 

The  DBCS  has  a  trace  option  (DEOFTD  options  !*  and  5)  wnich 
will  print  a  history  of  entrances  and  exits  to  c-ach  DBCS  subprogram. 

In  other  words,  a  message  is  printed  each  time  a  D3CS  sv'oprogran  is 
entered.  This  option  is  off  if  the  trace  code  is  one  and  on  if  the 
code  is  two.  The  DBCS  trace  is  useful  only  for  debugging  the  D§CS 
code  and  has  little  utility  in  debugging  application  programs. 

It  also  will  produce  a  great  deal  of  output.  Its  use  by  application 
programs  is  not  recommended,  since  its  purpose  is  to  aid  in  systems 
development . 

i 

The  DBCS  has  four  levels  of  error  processing  which  are  des¬ 
cribed  in  Section  VII.  They  are  coded  as  follows: 

1  -  information 

2  -  warning 

3  -  severe 

U  -  fatal 

The  error  print  flag  option  (DBOFTD  option  6)  is  one  of  these  numbers. 
Standard  DBCS  error  messages  are  printed  on  the  DBCS  output  file  when 
errors  of  severity  greater  than  or  equal  to  the  error  print  flag  occur. 
The  DBCS  default  for  the  error  print  flag  is  one.  This  is  also  the 
default  for  MOFADS. 

The  DB  protection  mode  options  for  DBOPTD  options  7  and  8  are 
given  in  Table  II-6. 


The  SAF  smoothing  constant  (default  *  0.5)  is  specified  vith 
D30PTD  option  9-  The  lower  and  upper  bound  on  the  SAF  update 
periods  are  specified  with  BBOFTD  options  10  and  11.  The  DBCS 
defaults  are  75  and  125 ,  respectively,  't’he  MOPADS  Bettings  for 
these  options  are  150  and  250.  The  DBCS  samples  uniformly  between 
these  values  to  determine  the  next  update  point  for  SAF's.  The 
default  values  selected  here  are  somewhat  arbitrary  and  may  be 
changed  as  experience  is  gained  vith  the  DECS. 

The  effect  of  these  three  parameters  is  as  follows: 


a.  The  values  specified  are  used  for  SAF  updates  until 
they  are  again  changed  or  until  another  working 

DB  is  opened. 

b.  When  a  DB  is  closed  (either  working  or  reference), 
the  current  values  of  SAF  and  the  min  and  max 
update  period  are  written  to  the  DBF. 

c.  When  an  old  DBF  is  opened  as  the  working  DB, 
the  values  of  SAF  and  the  min  and  max  update 
period  are  read  from  the  DBF.  They  become 
the  current  values  and  are  used  in  accordance 
with  (a)  and  (b)  above. 

With  option  12  and  13,  the  user  can  specify  the  number  of  print 
columns  and  the  number  of  lines  per  page  for  the  DBCS  output  file 
and  the  trace  file.  The  printing  device  must  have  at  least  80  columns. 


Option  lU  allows  the  user  to  specify  the  number  of  words  per 
record  for  the  DBF.  The  DBCS  will  function  vith  any  record  size 
greater  than  16  words.  This  parameter  should  be  set  once  for  the 
computer  installation  to  optimize  dick  access  speed.  Most  computer 
systems  achieve  maximum  disk  access  efficiency  if  the  record  size 
is  an  even  multiple  of  the  disk  sector  size. 

The  number  of  words  per  record  is  a  characteristic  of  the  DBF 
not  the  DBCS,  When  a  new  DB  is  opened,  the  DBCS  will  read  the  record 
size  from  the  DBF  and  adjust  accordingly.  The  exception  to  this 
is  that  both  the  working  and  reference  DB's  must  have  the  same 
record  size. 

Options  15,  16,  and  17  allow  the  user  to  adjust  the  sizes  of 
the  internal  and  temporary  stores.  The  internal  stores  must  have 
at  least  three  records  and  there  is  no  benefit  to  increasing  their 
sizes. 
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As  discussed  in  Section  II,  3-0,  the  DBCS  partitions  its  main  ,-.-77 

storage  arrays  to  provide  storage  for  the  TS  and  VS.  The  number  • 

of  records  specified  in  options  1 6  and  17  are  allocated  to  the  TS.  l.-Ly] 


All  remaining  available  space  is  allocated  to  the  WS.  This  permits 
the  user  to  change  the  proportion  of  Epace  allocated  to  the  TS  and 

WS  storage  areas. 


The  storage  allocation  is  a  characteristic  of  the  DBCS:.  not 
the  EBF’s.  In  other  words,  the  DBF  is  not  structurally  affected 
by  these  parameters.  Options  15,  1 6,  and  17  may  not  be  changed 
while  any  data  base  is  open,  however.  The  DBCS  will  raise  an  error 
if  either  a  working  or  a  reference  DB  is  open  when  a  request  to 
change  one  of  these  options  is  made. 

2-16.  Internal  and  External  Sequential  Data  Bases. 

Subroutine  W2RWD  will  create  or  write  sequential  internal 
or  external  formatted  representations  of  data  base  files.  These 
files  have  the  following  characteristics. 

Internal  Format  -  sequential,  unformatted,  variable 

length  records.  No  record  exceeds 
the  length  of  the  data  part,  however. 

External  Format  -  sequential,  formatted,  variable 

length  records.  No  record  exceeds 
80  characters,  however. 

The  internal  format  can  be  used  to  archive  DBF’s  on  tape  or  to  trans¬ 
fer  them  among  similar  computer  systems.  The  external  format  can  be 
used  to  archive  DBF's  on  tape  and  to  transfer  then  among  dis-similar  com¬ 
puter  system.  The  direct  access  data  base  file  to  be  written  or 
read  must  not  be  opened  as  the  working  or  reference  DB  when  W2RWD  is 
called.  Furthermore,  if  a  sequential  access  file  is  being  read  to 
create  a  new  direct  access  DBF,  the  DBF  file  will  be  opened  with 
STATUS  =  'NEW'  and  will  have  the  record  size  specified  on  the  sequential 
access  file. 

2-17.  Printing  the  Data  Store. 

Subroutine  PSTOKD  prints  the  contents  of  the  DBCS  data 
store  (IS,  TS,  WS)  to  the  DBCS  output  files.  This  is  a  debugging  tool 
only,  and  should  normally  never  be  required. 


VII.  ERROR  PROCESSING 


1-0  SUBROUTINE  ERRORD. 

The  single  error  processing  subprogram  in  the  DBCS  is 
Subroutine  ERRORD.  When  an  error  is  detected,  ERRORD  is  called 
with  the  error  code,  an  text  message,  the  name  of  the  calling 
program  and  a  list  of  integer  and  real  parameters.  If  the 
error  print  flag  permits  (see  2-0  below),  a  message  is  printed 
on  the  DBCS  output  file.  In  addition,  actions  are  performed 
which  are  conditional  upon  the  severity  o t  the  error.  This 
severity  is  determined  by  the  value  of  the  error  code  as  in 
Table  VII-1. 

Table  VII-1.  Error  Severity  Codes. 


Error  Code 

Severity  Coda 

Severity 

+  1-1999 

1 

Informat i  n 

+  2000-2999 

2 

Warning 

+  3000-3999 

3 

Severe 

+  hcoo- 

k 

Fatal 

' r.fcrmat ion  errors  indicate  requested  actions  that  cannot  be  performed. 

-ning  errors  are  similar  to  Information  errors  but  are  Judged  to 
.<■_>  more  severe  in  that  they  reflect  a  serious  mis- judgement  or  mis¬ 
take  by  the  user.  The  difference  between  these  two  is  subjective 
since  ERRCRD  treats  them  essentially  the  same.  After  the  error 
"cage  is  printed  (conditioned  on  the  error  print  flag)  a  RETURN 
ecuted  from  ERRORD.  The  calling  DBCS  program  will  normally 
; t  its  activity  and  return  (with  the  error  code)  to  the  calling 
.plication  program. 

Severe  errors  imply  that  the  user  program  has  attempted  to 
destroy  the  integrity  of  the  DB,  has  violated  DBCS  conventions,  or 
a  computer  system  error  has  been  detected.  In  this  case,  ERRORD  will 
update  \:,o  DB  (i.e.,  make  the  disk  version  identical  to  the  5.n-core 
vers: cn),  set  the  DB  to  read-only,  and  return.  If  subsequent  errors 
occ  •  during  these  activities,  execution  will  terminate  immediately. 


Fatal  errors  occur  when  indicators  of  faulty  data  bases  are 
detected  or  certain  crpacity  limitations  are  exceeded.  ERRORD 
performs  the  same  actions  as  for  Severe  error  except  that  it  ter¬ 
minates  execution  instead  of  RETURNing. 

2- 0  THE  ERROR  PRINT  FLAG. 

As  discussed  in  Section  VI,  2-15,  the  DBCS  error  print  flag 
can  be  used  to  suppress  printing  from  Subroutine  ERRORD.  The  error 
print  flag  is  set  to  one  of  the  error  severity  codes  in  Table  VII-1 
Printing  is  then  suppressed  for  any  error  with  a  severity  code  less 
than  the  error  print  flag.  The  default  error  print  flag  is  one. 

3- 0  DBCS  ERROR  CODES. 


3-1.  Information  Errors. 


Error  Code 


Description 


1 

2 

3 

k 

5 

6 

T 

8 

9 


11 

12 

13 

lU 

15 

16 


Working  data  base  not  open. 

Reference  data  base  not  open. 

No  output  file  available. 

Invalid  DBA  fcr  specified  purpose. 

Attempt  to  access  DL  or  DR  with  invalid  elements 

Attempt  to  read  beyond  the  end  of  a  DL  (see 
Section  U-0  below). 

Force  read  flag  overwirtes  in-core  data  that  is 
not  on  disk. 

Attempt  to  write  to  read-only  DB. 

Attempt  to  access  two  dimensional  DL  with 
incorrect  dimensions. 

Attempt  to  access  a  DL  with  wrong  data  type 
(reel,  integer,  etc.). 

DBAA  not  current  when  it  is  required  to  be. 

DBAA  not  a  DL  when  it  should  be. 

Not  used. 


Attempt  to  create  a  DR  with  incorrect  or 
incompatible  ranking  codes. 

DRAA  not  a  DR  when  it  should  be. 

Incorrect  conditions  specified  for  search  of  a 
directory. 

Invalid  option  to  DBOPTD.  Examine  integer 
parameter  1. 


L7 


18 


-9 


20 

21 

22 


Invalid  unit  number..  S*  e  integer  parcaeter  1. 

Insufficient  rov/rolumn  specification  for 
DBCS  output  or  trace  file.  See  letter 

parameter  1. 

Unit  nue.be*  invalid  or  already  used.  See 
integer  pa-aaeter  1. 


Bo  reference  E3  may  be  open 
operation. 

Direct  accei -  DDE  not  empty, 


during  this 


>2. 


Error  Code 

*2000 

2001 

2002 


2003 

200 

2005 

2006 


3-3. 


Warning  Errors. 

Description 

I  ) 

Bo  sore  records  available. 

Attempt  to  del.rte  a  directory  that  la  not  empty. 

Attearpt  to  insert  incorrect  type  (DD  or  DR) 
into  a  directory. 

Attempt  to  open  a  DB  vithout  prior  call  to  IBTTD. 

Attempt  to  change  the  unit  number  of  an  open  DB. 

Both  ES’s  must  be  cloned  in  order  to  reconfigure 
the  data  store. 

Record  length  too  short.  See  integer  parameter  1 

* 

Severe  Errors. 


Error  Code 


Description 


3000 
3001 
3002 
3003 
300 1* 

3005 

3006 


1  Attempt  to  open  a  D.3  vith  record  size  different 
I  ,  from  the  current  size. 

Attempt  to  open  a  DB  with  control  port  size 
different  from  the  current  size. 

Attempt  to  open  a  DB  with  data  part  size 
different  from  the  current  size. 

Attempt  to  open  a  DB  with  variable  NWADD 
different  from  current  size. 

System  1/0  error.  Integer  parameter  1  is  the 
system  error  code. 

I 

Attempt  to  create  character  |DL  with  too  many 
cbaracters/elements.  Maximum  allowed  is 
integer  parameter  1. 

Internal  DBCS  system  error. '  Attempt  to  return 
record  number  zero  to  the  ARL. 


1 


U-117 
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3-1*.  Fatal  Errors 


Error  Code 

tooo 

too: 

1*002 

1*003 

&00l* 

1*005 

1*006 

1*007 

1*008 

1*009 

1*010 

1*011 


Description 

Invalid  number  of  words /record. 

Insufficient  storage  in  the  data  a*cre. 

A  record  has  been  read  which  indicate**  a 
faulty  DBF  update  (negative  record  number). 

Internal  store  exhausted.  (See  C8CP7D  option  15). 

Mismatch  between  actual  record  type  and  the  I3AA 
type.  Integer  parameter  1  is  record  number. 

Attempt  to  accese  invalid  record  (record  number 
is  .LE.i  or  .G?.MXP,D(2 ,-) . 

Incorrect  index  of  KliPD  array  sent  to  KPNPD. 

Reference  SB  record  found  in  working  store  or 
attempt  to  swap  reference  DB  record  into  WS. 

A  DL  is  not  in  the  DR  specified  in  its  control 
part. 

Insufficient  internal  vork  space.  Increase  size 
of  KW0RKD.  Minimum  needed  is  integer  parameter  1. 

A  DR  is  not  in  the  directory  specified  in  its 
control  part. 

Duplicate  records  found  in  the  data  store. 


U-0  SPECIAL  PROCESSING  OF  ERROR  CODE  SIX. 

Error  code  six  flags  an  attempt  to  read  past  the  end  of  a  DL. 
This  action  is  frequently  done  on  purpose  to  find  the  end  of  a  DL  or 
DR.  Therefore,  printing  of  the  error  message  is  usually  suppressed 
(regardless  of  the  value  of  the  error-print  flag).  The  DBCS  deter¬ 
mines  internally  when  to  suppress  printing.  In  general,  any  call 
from  an  application  program  that  reads  past  the  end  of  a  DL  will  have 
the  error  printing  suppressed  (the  error  code  value  of  six  is  still 
returned,  ho;  aver).  Errors  internal  to  the  DBCS  that  result  in  such 
an  error  will  not  be  suppressed,  however. 
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VIII.  COmON  VARIABLE  DEFINITIONS 


1-0  PARAMETERS 


Parameter  Raises 

Value 

Definition 

KXWH1CD 

100 

length  of  the  KVCHKD  array 

■CPWD 

fc 

number  of  chcuraeters/vord  for  the 
cceputer 

RCS7KD 

6100 

pusher  of  characters  in  the 
character  data  store  (CSTORD) 

RSTORD 

6000 

number  of  words  in  the  mmeri-* 
data  store  { KSTOED/STORD) 

2-0  C0KM0H/DBCS1D/ 

Variable  Raise  Default  Value 

Definition 

KCPD( 3) 

• 

defines  the  partition  of  the 
character  data  store 

KCPD(l)  -  1st  character  of 
the  IS 

(2)  -  lst  character  of 

the  TS 

(3)  -  1st  character  of 

the  WS 

knpd(9) 

- 

defines  the  partition  0f  the 

numeric  data  store.  See 

Table  II-U. 

kstord(nstokd)/ 

stord(nstord) 

- 

EQUIVALENCEd  arrays  that  hold  the 
numeric  data  store 

3-0  COMMON /DBCS 2D / 

Variable  Name  Default  Value 

Definition 

cstord*(ncsi.d) 

- 

character  variable  to  hold  the 

character  data  store 
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Uo  CCM40N/D2CS  3D/ 


Variable  Kane 

Default  Value 

Definition 

ALPHD 

0.5 

SAF  iraoothing  constant 

ITRCD 

1 

trace  code 

1ST0ED(!*,2,2) 

DRAA's  fcr  the  aaster  and  ayotess 
directories 

1SYBBD{  I EL, IMS, HIS) : 

IEL  *  cj-aents  1  to  h  of  the 
DRAA 

IKS  ■  1 -master  directory 
2-systas  directory 

51®  *  1-working  BB 

2-rc ference  UB 

ISYSD(2,2,2) 

DBAA's  for  the  director/  label 
and  directory  address  DL's  in 
the  system  directory. 

isysd(iel,ims,hd3) 

TEL  *  elements  1-2  of  the  DBM 
IMS  »  1-DR  label  data  list 

2-DR  adtb’.oss  data  list 
HDB  *  1-working  DB 

2-reference  DB 

JOUTD 

10 

DECS  output  file  unit  number 

JTRCD 

10 

trace  output  file  number 

KARLD(2,2) 

DBM’s  of  the  ARL's 

KARLD(lEL,NDB): 

IEL  *  elements  1  and  2  of 
the  DBM 

NDB  =  1-working  DB 

2-reference  DB 

KEPFD 

1 

error  print  flag 

KPRTD(2,2) 

( 132 ,132 \ 

\  6k,  6k  1 

output  characteristics  for  the 
output  (column  l)  and  the  trace 
(column  2)  files. 

Row  1  -  columns /page 

Row  2  -  lines/page 
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KSUP6D  1 

KVOHKD  ( KXVEKD ) 

LW>{2)  (-1,-2) 

KDLAD 

KFAD(2) 

MHDLAD  125 

KLDLAD  75 

MBSFDU) 

MODED(2) 

MXRD(2,2) 


NCDPD 

HCTSD(2)  (0,3) 

KCtfSD 

IJDLAD 


error  code  6  suppression  flag 

1  -  print  error  6 

2  -  suppress  printing  of 

error  6 

internal  DBCP  working  storage 

IS  unit  numbers  ((l)-vorking, 
(2)-reference)  Negative  if 
CB  is  not  open 

nuaber  of  IS  accesses  required 
till  the  next  SAF  update 

I8CSA  in  working  a ndf.  temporary 
store  of  the  first  unused 
record  slot,  (l)-maserir.*, 
(2)-character 

KDLAD  is  uniformly  distributed 
between  KLDLAD  and  WIDLAD- 
MOPADS  defaults  for  these 
variables  are  150  and  250 

2BCSA  of  the  VS  record  with  the 
minima  SAF.  (l) -numeric, 
(2)-character 

protection  modes  ((l)-working  DB, 
(2)-reference  DB) 

MXRD(l.i)  -  maximum  record  num¬ 
ber  allowed  (0  for  no  limit). 

JCCRD(2,i)  -  largest  record 
number  used  so  far  for  DB  i. 

i  =  (l) -working,  (2) -reference 

number  of  characters  in  the  data 
part  of  each  record 

number  of  records  of  storage 
available  in  the  character  TS. 
(l) -current ,  (2)-default  value 

number  of  records  of  storage  for 
the  character  WS 

number  of  DB  accesses  since  last 
SAF  update 


■1SD 

k 

number  of  record*  of  storage  in 
the  13  (both  nuaeric  and 

character 

RTSD(2) 

(0,5) 

number  c.f  record*  of  storage 
available  for  the  nuaeric  TS 
{ 1 5-cur  rent  value, (2) -default 

RVABD 

2 

number  of  word*  of  addressing 
information  in  addition  to  the 

ID  in  the  data  part  of  a  direc¬ 
tory.  In  other  words,  the  number 
of  rows  in  a  directory  is  the 
length  of  the  ID’s  plus  BWABD. 
See  Section  II,  1-2. 

JTrfCPD 

10 

the  number  of  words  in  the  con¬ 
trol  part  of  each  record 

JfWDFD 

- 

number  of  words  in  the  data  part 
of  each  record 

HWRECD(2) 

(o,6M 

number  of  words  per  record.  ( 1)— 
current,  (2) -default 

NWSD 

- 

number  of  records  of  storage 
available  in  the  numeric  WS. 

OALPHD 

- 

l.-ALPHD 

SAFMND(2) 

- 

value  of  the  minimum  SAF  of  any 
record  in  the  WS.  (1 5-numeric, 
(2)-character 

TDLA.D 

cumulative  total  of  DB  accesses 

5-0  COMIiON/DBCSto/ 

Variable  Name  Default  Value  Definition 

CDBFD(2)*35 


blank 


file  names  of  the  working  and 
reference  DB’s 
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PREFACE 


This  report  contains  chanyes  dated  14  May  1982 
which  are  not  upward  compatible  with  the  29  July 
1981  revisions.  Users  who  have  applications  utili¬ 
zing  this  earlier  version  should  retain  pr:  or  copies 
of  this  report  for  reference.  The  non-upward  com¬ 
patible  features  involve  the  use  of  the  line  ter¬ 
minator  character  and  subroutines  FFPAC3 ,  FFCPYI 
and  FFCPYO. 
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SECTION  I 


INTRODUCTION 

A  set  of  FORTRAN  77  subprograms  is  presented  here  that 
permit  input  of  data  without  regard  to  column  spacing  on  the 
input  device.  The  system  maintains  an  internal  buffer  array 
into  which  input  records  are  read.  The  buffer  cam  individually 
address  the  characters  in  the  record.  The  buffer  is  then 
searched  for  a  field  of  data  that  is  delineated  by  user  speci¬ 
fied  separator  characters.  When  a  field  is  found  it  is  inter¬ 
preted  as  n  datum  of  the  appropriate  type.  When  the  user  next 
requests  a  data  item,  the  buffer  is  searched  from  the  point 
where  the  last  field  was  encountered.  This  continues  until 
the  internal  buffer  is  exhausted.  Then  a  new  record  is  read 
into  the  buffer  and  the  process  repeats. 

Several  options  and  environment  parameters  can  be  speci¬ 
fied  by  the  user.  A  brief  description  of  these  follow. 

Input  and  Output  Files 

An  input  file  must  be  specified  with  each  call  to  the 
system  for  data.  No  default  input  file  is  provided. 
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An  output  file  must  alee  be  specified.  The  default 
output  file  is  unit  6.  The  output  file  is  used  for  print¬ 
ing  error  messages.  If  an  invalid  output  file  unit  number 
is  specified,  a  warning  message  will  be  printed  and  the 
program;  will  abort  if  any  data  is  subsequently  erroneously 
entered.  The  user  is  responsible  for  providing  a  file 
with  the  appropriate  unit  number. 


Data  Echo  File 

Another  file,  which  may  be  the  same  as  the  output  file, 
may  be  specified  as  the  echo  file.  Each  record  will  be 
written  to  the  echo  file  as  it  is  read.  The  default  condition 
is  no  echoing  of  data. 

Error  Processing 

The  system  provides  two  levels  of  error  processing: 
interactive  and  batch.  For  batch  processing,  error  messages 
are  printed  and  execution  is  terminated.  With  interactive 
processing,  the  user  is  given  the  opportunity  to  re-enter 
erroneous  data.  The  default  condition  is  interactive. 

Numeric  Field  Validity  Checking 

The  option  for  checking  for  valid  numeric  fields  can  be 
either  "on"  or  "off."  If  it  is  on,  each  request  to  interpret 
a  field  as  a  number  results  in  an  examination  of  the  field 
for  validity.  The  default  condition  is  "on"  and  is  recom¬ 
mended  for  interactive  use.  The  FF1N  system  is  slower  than 
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standard  formatted  data  input,  and  it  is  not  recommended  for 
reading  large,  tabular  data  files.  If  it  is  used  with  input 
files  which  the  user  is  confident  have  valid  numeric  fields, 
then  this  option  should  be  turned  "off." 

Line  Terminator  Character 

A  character  may  be  provided  which  terminates  processing 
of  a  record.  If  this  character  is  encountered  in  the  buffer, 
the  remainder  of  the  buffer  is  not  examined,  and  a  new  record 
will  be  read  when  additional  fields  are  needed.  Use  of  the 
line  terminator  character  will  speed  processing  on  short  records, 
and  it  permits  comments  to  be  placed  on  data  records.  The 
default  line  terminator  is  the  dollar  sign  ($)  .  The  line  ter¬ 
minator  character  is  not  interpreted  when  in  a  quote  field 

/ 

(see  "The  Quote  Character") . 

Field  Separators 

Fields  are  separated  by  separator  characters.  Up  to  five 
separator  characters  may  be  specified.  Two  are  provided  by 
default  (blank  and  comma) .  There  is  no  hierarchy  among 
separators,  and  multiple,  consecutive  separators  are  treated 
as  a  single  separator.  Thus  the  following  records  are  equivalent. 
10,  20,  30 
10, ,,20  ,  ,30 

10  20  30  $ 

Any  character  which  is  not  a  separator,  a  quote  (see  the  next 
page)  or,  in  some  cases,  a  line  terminator,  is  part  of  a  field. 

No  characters  are  ignored. 


The  Quote  Character 

Sometimes  it  is  desirable  to  have  a  separator  character 
or  the  line  terminator  character  contained  in  a  field.  For 
example,  blanks  are  by  defau'.t  separators;  however,  a  blank 
may  be  desired  in  an  alphanumeric  or  a  numeric  field.  Such 
fields  may  be  enclosed  in  quote  characters.  The  default  quote 
character  is  the  double  quote  mark  (").  Any  field  can  be 
enclosed  in  quotes.  When  a  quote  is  the  first  non-separator 
character  in  a  field,  the  system  stops  searching  for  separator 
characters  and  line  terminators  and  instead  searches  for  a 
matching  quote  to  end  the  field.  The  quote  marks  are  not 
part  of  the  field.  For  example,  the  following  are  not  equi¬ 
valent  fields 

GO  TO 
"GO  TO" 

GO  TO  is  two  fields;  "GO  TO"  is  one.  Quote  marks  are  useful 
mostly  for  alphanumeric  or  character  fields,  but  they  can  be 
used  with  any  field.  Zn  particular, 

3" 

would  be  interpreted  as  -0.0003  (BLANK=ZERO)  or  -.3  (BLANK  * 
NULL) . 


Hollerith  Character  Count 

FFIN2  supports  Hollerith  data  for  compatibil ity  with 
older  systems.  The  user  can  specify  the  number  of  characters 
that  he  wishes  to  read  per  word.  This  option  defaults  to  one 
character  per  word. 
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The  user  can  specify  the  number  of  columns  (jp  to  132) 
to  be  read  from  the  input  file  and  the  number  of  columns  to 
be  examined  for  valid  data.  This  permits  the  data  to  have 
identifiers  at  the  end  of  each  record  which  are  not  examined 
by  FFIN2.  The  defaults  are  90  columns  read  and  80  columns 
examined . 


SECTION  II 
USE  OF  THE  INPUT  SUBPROGRAMS 

i  •  . 

This  section  describes  the  subprograms  used  for  reading 
data  with  FFIN2.  Section  III  presents  several  utility  sub- 

i 

programs  which  can  be  used  for  changing  the  default  options 

| 

and  parameters.  Section  IV  contains  programs  for  advanced 
users  who  need  to  change  the  normal  sequence  of  processing 
the  buffer. 

Six  types  of  data  fields  are  recognized  by  the.  FFIN2 
programs:  character,  logical,  double  precision,  real,  integer, 
and  Hollerith.  In  general,  FFIN2  will  recognize  any  field 
within  these  six  types  that  FORTRAN  will  accept.  Alphanumeric 
and  logical  fields  can  be  of  any  length  so  long  as  they  fit 
within  a  record.  No  field  may  ever  be  split  by  the  end  of  a 
record.  All  numeric  fields  are  limited  to  ?0  characters. 

Each  call  to  one  of  these  subprograms  returns  a  single  datum. 
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FFL 

FFL  will  return  the  value  of  a  logical  variable.  The 
calling  sequence  is: 

SUBROUTINE  FFL  (LTF ,  JRD)  . 

LTF  must  be  type  logical,  and  JRD  is  the  input  file.  An 
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error  is  generated  if  the  first  non-blank  character  of  the 
next  field  is  not  a  "T"  or  "F." 


FFD 

FFD  will  return  the  value  of  a  double  precision  vari¬ 
able.  The  calling  sequence  is: 

SUBROUTINE  FFD  (DVAR,  JRD)  . 

DVAR  must  Le  'cufole  precision,  and  JRD  is  the  input  file. 

The  "D"  notation  may  be  used  with  double  precision  input 
fields,  e.g.,  3.4D1.  Double  precision  fields  are  converted 
with  a  D20.0  specification. 


FFR 

FFR  will  return  the  value  of  a  real  FORTRAN  variable. 
The  calling  sequence  is: 

SUBROUTINE  FFR  (RVAR,  JRD)  . 

RVAR  must  be  type  real,  and  JRD  is  the  input  file.  Real 
fields  are  converted  with  a  G20.0  specification. 

FFI 

FFI  will  return  the  value  of  an  integer  FORTRAN  vari¬ 
able.  The  calling  sequence  is: 

SUBROUTINE  FFI  (IVAR,  JRD) . 

IVAR  must  be  type  integer,  and  JRD  is  the  input  file. 
Integer  fields  are  converted  with  an  120  specification. 
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FFC  will  return  alphanumeric  data  as  character  vari¬ 
ables.  The  calling  sequence  is: 

SUBROUTINE  FFC  (CHAR,  NC,  LCHAR,  JRD). 

CHAR  is  a  CHARACTER  array  of  length  NC.  FFC  will  return 
the  next  fi^ld  in  CHAR  with  LC  «min  [LCHAR,  LEN ( CHAR ( 1 ) )  ] 
characters  per  "word."  If  the  field  has  fewer  than  NC*LC 
characters,  the  remainder  of  CHAR  is  blank  filled.  If  the 
field  has  more  than  NC*LC  characters,  the  right  most  excess 
characters  are  ignored. 

FFA 

Subroutine  FFA  will  return  an  alphanumeric  field  as 
Hollerith  data.  The  calling  sequence  is: 

SUBROUTINE  FFA  (LALPH ,  NALPH,  JRD). 

r 

LAL1H  is  an  integer  array  of  length  NALPH.  JRD  is  the  input 

j  i 

file.  Say  the  current  alphanumeric  character  count  is 

i 

NOWCHR.  The  first  (from  the  left)  NALPH  *  NOWCHR  characters 
of  the  next  field  will  be  read  into  LALPH  with  NOWCHR  charac¬ 
ters  per  word.  Any  excess  is  ignored.  If  the  field  has  fewer 
characters  than  NALPH  *  NOWCHR,  the  remaining  words  of  LALPH 
will  be  blank  filled.  FFA  is  the  only  non-ANSI  FORTRAN  77 
subprogram  in  FFIN2 . 


^  4WJP^»$!jjjfll*jEi  .■  | 11 1  1  m  ■ 


FFCLR 

FFCLR  clears  the  internal  buffer.  The  calling  sequence 
is: 

SUBROUTINE  FFCLR. 

Any  unused  fieidu  in  a  record  will  be  ignored  after  a  call  to 
FFCLR.  The  next  call  to  one  of  the  above  FFIN2  programs  will 
result  in  a  new  record  being  read. 

Example  ^ 

Suppose  file  12  has  data  on  children  in  a  school.  Each 
record  contains  the  following  information: 

Last  name, first  name, M  or  F,  age,  height,  weight. 

The  first  three  fields  are  alphanumeric.  M  or  F  specifies 
male  or  female.  Age  is  an  integer  number  and  height  and 
weight  are  decimal  numbers. 

If  we  want  to  collect  statistics  on  the  height  and  weight 
of  all  boys  between  the  ages  cf  9  and  eleven  we  could  use  the 
following  code. 


CHARACTERS  FIRST,  LAST 
REWIND  12 

100  CALL  FFC (LAST,  1,  8,  12) 
CALL  FFC (FIRST,  1,  8,  12) 


CALL  FFA(MF,  1,  12) 

IF (MF.EQ. 1HM)  GO  TO  150 
120  CALL  FFCLR 
GO  TO  100 

150  CALL  FF1 (IAGE,12) 

IF (IAGE.LT. 5. OR. IAGE.GT.il)  GO  TO  120 
CALL  FFR (HEIGHT,  12) 

CALL  FFR (WEIGHT,  12) 

collect  statistics 

GO  TO  100 

If  a  record  is  not  for  a  boy,  the  remainder  of  the 
information  is  discarded  at  statement  120,  and  a  new  record 
is  read.  The  age  criteria  are  checked  after  statement  150. 
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USE  OP  FFIN2  UTILITY  SUBPROGRAMS 

Subprograms  are  px  ovided  for  use  in  changing  the 
default  options  and  for  use  in  identifying  key  words  for 
syntax  processing. 

FFSET 

FFSET  is  used  to  change  options  in  the  FFIN2  system. 

The  calling  sequence  is : 

SUBROUTINE  FFSET (IOPT,  LOPT,  NOPT.  COPT,  NCR). 

I  OPT  is  the  option  code  and  has  one  of  the  following  values. 

1  -  set  output  file  number 

2  -  set  echo  file  number 

3  -  set  error  processing  mode 

4  -  set  numeric  field  validity  option  "on"  or  "off 

5  -  set  new  quote  character 

6  -  set  ner  lint  terminator  character 

7  -  set  new  separators 

8  -  not  used 

9  -  set  the  Hollerith  character  count 

10  -  set  input  record  length  parameters 

* 

LOPT  is  a  one  dimensional,  integer  array  of  length  NOPT.  LOFT 
contains  the  new  values  to  be  set  for  the  options  that  require 


numbers.  COPT  is  a  CHARACTER  *1  array  of  length  NCR  and 
contains  alphanumeric  option  data. 

1.  Output  File  Number.  To  set  the  output  file  number  to 
N,  use: 

CALL  FFSET  (1 ,  N,  1,  *  • ,  1) . 

A  warning  will  be  printed  if  N  <  0. 

* 

2.  Echo  File  Number.  To  set  the  echo  file  to  N,  use: 

CALL  FFSET  (2,  N,  1,  '  1). 

If  N  <  0,  no  echo  of  input  records  will  take  place. 

3.  Error  Processing  Option.  To  set  the  error  processing 
mode ,  use: 

CALL  FFSET  (3,  N,  1,  1  \  1). 

If  N  »  0,  then  interactive  error  processing  is  selected. 

I  • 

If  N  f  0,! batch  operation  is  assumed ,  and  execution  will 

terminate  if  a  bad  field  is  encountered. 

j 

h 

4.  Numeric  Field  Checking  Option.  To  specify  the  numeric 
field  checking  option  use: 

CALL  FFSET  <4,  N,  1,  •  ’  ,  1)  . 

If  N  •  0,  fields  will  be  checked.  If  N  f  0,  no 
checking  is  done  of  numeric  fields. 


5.  Quote  Character.  To  set  the  quote  character  to,  say  a 
colon  ( : )  use : 

CALL  FPSET  (5,  0,  1,  •:*,  1). 

6.  Line  Terminator  Character,  To  set  the  line  terminator 
character  to,  say  a  semicolon (;)  use: 

CALL  FPSET  (6,  0,  1,  1). 

7.  New  Separators.  To  specify  4  separators  which  will  be, 
say,  conma  <t),  slash (/},  blank  (  ),  and  period  (.)  use 

CHARACTER* 1  IS (4) 

DATA  IS #  '  \ 

CALL  FFSET  (7,  0,  1,  IS,  4). 

The  new  set  of  separator z  completely  replaces  the  old 
set,  so  the  IS  array  above  must  contain  all  of  the 
separators  that  the  user  wants  in  effect  after  the  sub¬ 
routine  call.  No  more  than  five  separators  are  per¬ 
mitted. 

8 .  Not  Used. 

9.  Hollerith  Character  Count.  To  set  the  alphanumeric 
character  count  to  N,  use: 

CALL  FFSET  (9,  N,  1,  '  ',1). 

If  N  <  0,  the  Hollerith  character  count  is  set  to  one. 


10.  Input  Record  Length.  To  set  the  input  record  length 
parameters  use: 

CALL  FFSET  (10,  LOPT,  2,  '  1). 

LOPT(l)  is  the  number  of  columns  to  be  read  from  the 
input  file  (£132).  L0PT(2)  is  the  number  of  columns 

to  be  examined  by  FFIN2  (£L0PT(1)).  If  LOPT(l)  <  0, 

132  columns  will  be  read.  If  LOPT(2)  £  0,  then  LOPT(l) 
columns  will  be  processed. 


FFENV 

FFENV  will  print  the  current  environment  (separator 
characters,  options,  etc.)  on  the  output  file.  The  calling 
sequence  is: 

CALL  FFENV 

Figure  1  is  a  copy  of  the  output  produced  by  FFENV  for 
a  typical  condition. 


FRCt  FOR*  IM»V?  ENVIRONMENT 


OUTPUT  FILE. 

FILE  t 

ECHO  FILE 

NO 

INTERACTIVE  ERROR  PROCESS  INC 

YES 

WJHCRIC  FIELD  0*011*6 

YES 

QUOTE  CHARACTER- 

• 

LINE  TERM!  HAT  OH  CHARACTER- 

• 

FEA  CHARACTER  COUNT. 

4 

NLTWCR  OF  CQLUrWS  READ* 

M 

NUNBER  OF  COLLmS  PROCESSED. 

ta 

SEPARATORS!  X)m 

•  • 

Figure  1.  Output  From  FFENV  for  a  Typical  Environment. 
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IFFIND  and  IFFINC 


IFFIND  and  IFFINC  are  FUNCTION  subprograms  for  use  in 
identifying  key  words.  The  calling  sequence  is: 

FUNCTION  {ippi{Jc}  '  N'  I  CHAR)  . 

On  return,  IFFIN{£}  *  I  if  LARRY  (I)  »  ICHAR,  where  LARRY  is 
a  one  dimensional,  integer  (IFFIND)  or  character  (IFFINC) 
array  of  length  N.  If  ICHAR  is  net  contained  in  LARRY, 
IFFINf^}  =  0.  These  functions  can  be  used  to  identify  key 
words  as  follows: 

CHARACTER *5  KEY  (n) ,  KWORD 

DATA  KEY/ ' keyword  1  * , * keyword  2 ' , - / 

100  CALL  FFC (KWORD,  1,  5,  JRD) 

J  «  IFFINC  (KEY,  n,  KWORD) 

branch  to  syntax  processing  or  error. 

IBFIND  and  IBFINC 

IBFIN{£}  are  FUNCTIONS  similar  to  IFFIN{£}  except  that 
IBFINf^}  uses  a  binary  search  method.  The  calling  sequence  is 

FUNCTION  IBFIN{°}  (LARRY, N, ICHAR, NDEX) . 

LARRY,  N,  and  ICHAR  are  as  defined  for  IFFIN{£}  .  NDEX  is  a 
one  dimensional  array,  NDEX(N).  LARRY  need  not  be  arranged 
in  the  correct  collating  sequence  by  the  user.  This  will  be 


i  *V  '  ■'  •’  ’''■>  '  '■  ■  :  ■  '  -  J  '  ■■  ,,  '  , 
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done  internally.  On  the  first  call  to  IBFIN{J;},  NDEX(l) , 
must  be  equal  to  zero.  This  indicates  to  the  program  that 
LARRY  must  be  indexed  in  NDEX  according  to  the  computer's 
collating  sequence.  IBFIN{^}will  call  COLAT{^}  (see  Section 
IV)  to  do  tMs. 

The  LARRY  array  is  not  physically  rearranged;  NDEX  is 
returned  as  a  cross-reference  index  array.  The  values  of 
NDEX  must  not  be  changed  by  the  user.  IBFIN{°)  returns  the 
location  of  ICHAR  in  LARRY. 

To  use  IBFINC  in  the  example  for  IFFINC,  add  statements 
DIMENSION  NDEX (n)  and  DATA  NDEX(l)/0/.  Change  the  "J="  state¬ 
ment  to  J  *  IBFINC  { KEY, n,KWORD, NDEX ) . 
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SECTION  IV 

FFIN2  PROGRAMS  FOR  ADVANCED  USERS 

Several  subprograms  are  available  which  permit  the  user 
to  gain  access  to  the  contents  of  the  internal  buffer  and  to 
affect  the  sequence  in  which  the  FFIN2  programs  process  the 
fields  contained  on  a  record.  Also,  it  is  possible  t.o  use 
the  error  processing  programs  in  FFIN2  to  report  user 
detected  errors. 

FFCPYO 

Subroutine  FFCPYO  will  copy  a  portion  of  the  internal 
buffer  out  to  a  local  CHARACTER  variable.  The  calling 
sequence  is : 

SUBROUTINE  FFCPYO (IMNE ,  NC,  11,  12). 

ILINE  is  a  CHARACTER  variable  of  length  NC.  II  and  12  are 
the  first  and  last  characters  to  be  copied  from  the  buffer. 

On  return,  ILINE (1:NC)  contains  buffer  contents  from  chara- 
cater  II  to  12.  II  and  12  correspond  to  columns  on  the 
input  record.  If  II  is  less  than  1  or  II  is  greater  than 
MCOLRD* ,  no  action  is  taken  and  no  warning  is  given.  If  12 
is  less  than  II  or  greater  than  MCOLRD*,  12  «  MCOLRD  is  used. 
No  more  than  NC  characters  will  be  copied  into  ILINE.  FFCPYO 
permits  the  user  to  examine  fields  in  the  buffer. 

*  See  Section  V  for  MCOLRD. 
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FFCPYI 

Subroutine  FFCPYI  will  copy  the  contents  of  a  local  CHARA¬ 
CTER  variable  into  the  internal  buffer.  The  calling  sequence  is; 

SUBROUTINE  FFCPYI (ILINE ,  NC,  II,  12). 

I LINE  is  a  CHARACTER  variable  of  length  NC  containing  informa¬ 
tion  to  be  copied  into  the  buffer.  II  is  the  first  character 
in  the  buffer  to  be  changed  and  12  is  the  last.  A  maximum 
of  12  -  II  +  1  characters  will  be  copied  into  the  buffer. 

If  12  -  II  +  1  is  less  than  NC,  the  excess  in  ILINE  will  be 
discarded.  If  it  is  greater,  the  excess  in  the  buffer  will 
not  be  altered. 

If  II  is  greater  than  12,  no  copy  will  occur,  and  no 
warning  will  be  given.  If  II  is  less  than  1,  FFCPYI  will  use 
II  *  1.  If  12  is  greater  than  MCOLRD* ,  use  12  =  MCOLRD. 

FFCPYI  does  not  alter  the  current  pointers  to  the  buffer. 

FFINI 

Subroutine  FFINI  sets  the  internal  pointers  so  that  the 
internal  buffer  will  be  examined  from  its  beginning.  FFINI 
is  useful  when  an  input  record  is  to  be  re-examined  or  when* the 
buffer  is  loaded  by  the  user.  The  calling  sequence  is: 
SUBROUTINE  FFINI (JRD ,MTY) . 

JRD  is  the  input  file  number.  MTY  is  an  output  variable  that 
is  returned  with  the  following  values: 

1  -  the  buffer  is  not  empty.  FFINI  has 
terminated  normally. 

*  See  Section  V  for  MCOLRD 
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FFINI 


2  -  The  buffer  is  empty  (i,e.,  contains  no 
data  fields).  Therefore,  it  cannot  be 
positioned  at  its  beginning.  Upredictable 
results  will  occur  if  any  FFIN2  program  is 
subsequently  called  to  examine  the  buffer. 

The  options  are  to  load  the  buffer  again  with 
FFCPY1  and  call  FFINI  again  or  to  call  one  of 
FFA,  FFR,  FFD,  FFI ,  FFC,  or  FFL  to  cause  a 
new  record  to  be  read  from  an  input  file. 

will  echo  the  contents  of  the  buffer  ,if  option  two  is 


m  *<  4  *.  i 


greater  than  zero. 

FFINI  is  useful  to  examiile  records  th 
obtained  or  constructed  in  some  way  other  than  the  usual 
method  of  reading  from  an  external  file.  For  example  the 
following  lines: 

CHARACTER  *80  STUFF 

STUFF  =  ‘THIS  LINE  IS  USER  GENERATED' 

CALL  FFCPYI  (STUFF,  80,  1,  SC) 

CALL  FFINI  (5,  MTY) 

will  insert  STUFF  into  columns  1  through  80  of  the  internal 

i 

buffer,  and  FFINI  will  set  up  FFIN2  to  begjin  reading  'THIS'. 

FFLAST 

Subroutine  FFLAST  will  return  the  start  and  end  of  the  last 
processed  field.  The  calling  sequence  is: 

SUBROUTINE  FFLAST (11 ,  12). 


. 

alt  the  user  has 


y \ 

Ik  ’-<2? 


II  is  the  position  of  the  first  character  in  the  field  and  12 
is  the  position  of  the  last  character.  Quote  characters  will 
not  be  pointed  to  by  II  and  12.  II  and  12  may  be  used  as 
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inputs  to  FFCPYO  or  FFCPYI,  for  example.  Quote  fields  will 
automatically  be  taken  care  of  internally. 

If  FFLAST  is  called  after  any  of  the  input  subprograms 
in  Section  II,  II  and  12  will  point  to  the  field  that  was  just 
processed.  If  FFCLR  was  called  immediately  previous,  then 
II  ■  12  *  0  will  be  returned.  Zero  values  will  also  be 
returned  if  FFLAST  is  called  immediately  after  a  call  to 
FFNEXT  which  causes  a  new  record  to  be  read.  If  it  is  called 
immediately  after  FFSKIP,  II  and  12  will  point  to  the  field 
which  was  skipped.  FFNEXT  and  FFSKIP  are  discussed 
subsequently. 


FFNEXT 

Subroutine  FFNEXT  will  return  the  start  and  end  of  the 
next  field  to  be  processed."  The  calling  sequence  is; 

SUBROUTINE  FFNEXT  (II,  12,  IQUOT,  JPJD)  . 


11  and  12  will  be  returned  as  the  first  and  last  characters 
in  the  field  that  will  be  processed  by  the  next  call  to  an 
input  subprogram.  IQUOT  will  equal  zero  if  the  field  is  not 
in  quotes  and  will  equal  one  if  it  is.  The  characters  pointed 
to  by  II  and  12  are  not  quote  marks.  Characters  II  -  1  and 

12  +  1  will  be  the  quotes  if  IQUOT  =  1.  JRD  is  the  input  file. 
If  the  buffer  is  exhausted  when  FFNEXT  is  called,  a  new  record 
will  be  read,  and  II  and  12  will  point  to  the  first  field  on  it. 
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FFSKIP 

Subroutine  FFSKIP  will  skip  the  next  field  in  the 
buffer.  The  calling  sequence  is: 

SUBROUTINE  FFSKIP  ( JRD) . 

JRD  is  the  input  file.  A  call  to  FFSKIP  will  cause  the  internal 
pointers  to  be  moved  to  the  field  following  the  next 
field.  The  skipped  field  becomes  the  last  processed  field 
and  a  call  to  FFLAST  will  return  pointers  to  it. 

If  the  current  record  is  exhausted  when  FFSKIP  is 
called,  a  new  record  will  be  read  and  the  first  field  on  it 
will  be  skipped. 

FFRSET 

Subroutine  FFRSET  will  reset  the  internal  pointers  to 
a  specified  field.  The  calling  sequence  is: 

SUBROUTINE  FFRSET  (II,  IERR) . 

II  is  the  position  in  the  buffer  of  the  first  character  of  the 
field  the  user  wishes  to  be  processed  by  the  next  call  to 
the  input  subprogram.  In  other  words,  the  pointers  are  set  to 
process  the  field  starting  at  II  next.  FFRSET  will  check  to 
see  if  the  II  -  1  character  is  a  quote  and  will  process  the 
field  correctly  if  it  is.  The  II  character  may  not  be  a 
separator;  it  must  be  a  valid  field  character. 
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IERR  is  an  error  indicator  whose  values  have  the 

* 

) 

following  meaning:  j 

1  -  no  error  | 

2  -  II  <  0  or  II  >  80  J 

3  -  The  II  character  is  a  separator  ? 

j 

4  -  II  is  beyond  the  end  of  the  record. 

Internal  pointers  are  not  changed  if  IERR  is  greater  than  one. 

J 

FFPAC3  1 

'  ! 

Subroutine  FFPAC3  produces  error  messages  and  is  dis¬ 
cussed  more  fully  in  Section  V  where  the  calling  sequence  is 
given.  The  important  point  to  note  here  is  that  the  user  may 
call  FFPAC3  to  identify  a  bad  field.  Output  from  FFPAC3  is 
shown  in  Figure  2  for  an  invalid  numeric  field. 

v- 

{ 

IMPROPER  NUNERIC  FIELD 

FREE  FORM  ERROR  FIELB  UNDERLINES 

3.4E-.1 

CORRECTLY  RE-ENTER  BAB  FIELD  AND  REMAINDER 


Figure  2.  Output  from  FFPAC3  for  an  Invalid  Numeric  Field 
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FFPAC3  output  begins  with  the  message  "FREE  FORM  ERROR 
FIELD  UNDERLINED."  The  previous  message  indicating  a  bad 
numeric  field  is  printed  prior  to  the  call  to  FFPAC3.  The 
user  can  print  such  messages,  too,  and  then  call  FFPAC3  to 
underline  the  detected  error.  Use  a  FORMAT  statement  of  the 
following  form  to  be  compatibles 

FORMAT  {5X,  'user  error  message') 

Normally,  FFPAC3  will  prompt  the  user  to  re-enter  the 
record  starting  at  the  bad  field,  e.g.,  "CORRECTLY  RE-ENTER...." 
If  the  user  prefers  alternate  processing,  this  prompt  can 
be  suppressed  by  sending  IPRT  >  1  to  FFPAC3 . 

For  example,  suppose  an  improper  menu  selection  is 
made  daring  interactive  input.  The  programmer  :nay  want  to 
have  the  operator  immediately  try  again,  or  he  may  want  to 
print  the  menu  again  before  reading  a  new  menu  selection. 

Figure  3  shows  how  to  accomplish  each  of  these  cases. 

In  Case  1,  the  field  is  recovered  with  FFLAST  and  the 
error  underlined  with  FFPAC3 .  IPRT  ■  1  is  sent  to  FFPAC3 ,  so  the 
operator  is  prompted  to  correct  his  error  and  a  transfer  is 
made  to  statement  100  to  try  again.  In  Case  2,  IPRT  *  2  is 
sent,  so  the  operator  is  not  prompted  for  input  in  FFPAC3. 

After  return  from  FFPAC3 ,  the  menu  is  printed  again  and  then 
the  transfer  is  made  to  statement  100. 
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100  CALL  FFA  (XL,  1,  JRD) 


IF (bad  menu  selection)  GO  TO  200 


900  FORMAT  (5X,  ”YOTJ  ARE  CONFUSED") 

CALL  FFLAST  (II,  12) 

CALL  FFPAC3  (2,  II,  12,  JRD) 

• 

print  menu  again 
GO  TO  100  , 

Example  of  Use  of  FFPAC3  to  Generate  a  User  Error  Messagf 
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FFMTY 

Subroutine  FFMTY  permits  the  user  to  determine  if  the 
buffer  is  exhausted.  The  calling  sequence  is: 

SUBROUTINE  FFMTY (MTY) . 

MTY  is  returned  as  1  if  more  data  is  in  the  buffer.  It  is 
returned  as  2  otherwise.  FFMTY  is  useful  in  processing 
syntax  which  has  optional  fields  at  the  end  of  a  line.  It 
can  be  used  to  determine  when  a  call  to  an  input  routine  will 
cause  a  new  record  to  be  read. 

COLATC  and  COLATI 

Subroutines  COLAT(j)  will  order  a  one  dimensional  integer 
or  CHARACTER  array  in  least  to  greatest  collating  order.  The 
calling  sequence  is: 

SUBROUTINE  COLAT(j)  (ICOL,NROW,NDEX) . 

ICOL  is  an  array  dimensioned  to  ICOL(NROW).  The  NDEX  array 
is  dimensioned  NDEX(NROW),  and  is  returned  as  an  index  array 
for  ICOL.  ICOL  is  not  physically  rearranged. 

Let  JNEW  be  the  rank  of  an  entry  in  ICOL  in  the  collated 
ordering. 

Then : 

NDEX (JNEW)  is  the  physical  location  in  ICOL. 

r* 

COLAT { j }  is  not  intended  for  frequent  sorts  of  long  arrays. 
It  uses  a  simple  bubble  sort  and  will  be  inefficient  if  used 
for  repeated  sorts. 
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FFREAD 

Subroutine  FFREAD  loads  new  records  into  the  internal  buffer. 
FFREAD  is  user  written.  The  calling  sequence  is: 

SUBROUTINE  FFREAD  (JRD, MCOL, LIKE, IEOF)  . 

JRD  is  a  user  specified,  non-positive  code,  LINE (MCOL)  is  a 
CHARACTER  *1  array  and  IEOF  is  an  end-of-file  indicator.  If 
the  user  calls  an  FFIN2  program  with  JRD.GT.O,  FFREAD  is  not 
called;  FFIN2  reads  records  from  file  JRD.  If  JRD.LE.O,  however, 
FFIN2  calls  FFREAD  when  a  new  record  is  needed.  It  is  the  user's 
responsibility  to  load  LINE  with  the  desired  data.  If  IEOF  is 
returned  as  2,  FFIN2  end-of-file  processing  will  be  performed  and 
FFREAD  will  be  called  again.  FFIN2  sets  IEOF  *  1  and  LINE  *  blank 
on  input.  Cn  return,  the  contents  of  line  will  not  be  examined 
if  IEOF  *  2. 

The  user  may  need  to  provide  alternate  modes  of  loading 
the  buffer.  For  example,  input  from  a  graphics  terminal  may 
require  special  subprogram  calls  rather  than  a  READ  statement. 
Also,  the  user  may  wish  to  perform  certain  error  checking  on  j 
the  input  record  before  allowing  FFIN2  to  examine  it.  All  of 
this  can  be  done  in  FFREAD. 

To  provide  alternate  processing,  the  user  writes  FFREAD, 
loads  it  with  his  programs,  and  calls  FFIN2  programs  with 
non-positive  file  numbers.  The  supplied  version  provides  a 
guide  for  re-writing  FFREAD.  See  FFINI  for  another  method  to 
utilize  alternate  processing. 


NOTE 

A 

•No  FFIN2  programs  which  might  cause  a 
new  record  to  be  read  should  be  called 
from  FFREAD  since  these  programs  might 
cause  an  illegal  circular  call  to  FFREAD. 

FFPAC5 

FFPAC5  checks  logical  and  numeric  fields  for  validity. 

It  is  more  fully  discussed  in  Section  V.  It  can  be  used  to 
"look  ahead"  at  the  next  field  to  determine  if  the  field  is 
numeric  or  not.  Consider  the  following  statements 

NC0DE=5 

CALL  FFNEXT(Il,I2,IQU0TE,JRD) 

CALL  FFPAC5 (NC0DE,I1, 12, ICOND) 

IF (ICOND.EQ. 0)  THEN 
CALL  FFI (IVAR , JRD) 

ELSE 

alternate  processing 

ENDIF 

NCODE=5  (see  FFPAC)  specifies  an  integer  field.  FFNEXT 
delineates  the  next  field.  FFPAC5  examines  the  field  to  deter¬ 
mine  if  it  is  an  acceptable  integer  field.  If  so,  ICOND  is 
returned  as  zero  and  the  field  is  read  with  FFI.  If  not  some 
alternate  processing  is  performed. 

Note  that  if  option  4  (see  FFSET)  is  set  to  zero,  FFPAC5 
will  be  called  again  for  the  field  when  FFI  is  called. 
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FFSEP 

FFSEP  will  return  the  first  non-blank  separator  (FNBS) 
before  or  after  the  next  field  to  be  read.  The  calling 
sequence  is : 

SUBROUTINE  FFSEP  (IFB, SEP, ICOND) 

IFB  is  input  by  the  user.  If  IFB  *  1,  FFSEP  returns  the  FNBS 
preceding  the  next  field.  If  IFB  *  2,  it  returns  the  FNBS 
after  the  field.  SEP  is  a  CHARACTER  variable  returned  as  the 
non-blank  separator  or  as  blank  if  there  is  none.  ICOND  is 
output  as  the  condition  detected  by  FFSEP. 

ICOND  *  1  -  no  unusual  condition 

2  -  IFB  ■  1  and  there  is  no  previous 

field.  If  separators  precede  the 
next  field,  SEP  «  FNES  in  these 
separators.  If  not,  SEP  =  FNBS 
following  the  last  field  of  the 
last  record  (SEP  *  blank  if  the 
last  record  was  cleared  with  FFCLR) . 

3  -  IFB  **  1  and  the  current  record  is 

exhausted  (i.e.,  there  is  no  next 
field) .  SEP  *  FNBS  on  the  remainder 
of  the  field  or  blank  if  none. 

4  -  IFB  =  2  and  the  record  is  exhausted. 

SEP  =  blank. 

5  -  IFB  «*  2  and  the  next  field  is  the  last. 

SEP  3  FNBS  at  the  end  of  the  record. 
Unpredictable  results  occur  if  FFSEP  is  called  immediately  after 


aca’1  to  FFRSET 
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EXAMPLES 

Consider  the  following  record  with  separators  "1",  *2", 
"3" ,  and  "4". 

1  FIELDl  2  F1ELD2  3  FIELD3  4 

Next  Field 


Case 

to  be  read 

IFB 

SEP 

ICOND 

Description 

1 

FIELD2 

1 

"2" 

1 

normal 

2 

FIELD2 

2 

"3" 

1 

normal 

3 

FIELDl 

1 

*•  ^  •• 

2 

FIELDl  is  the  first 
field  on  the  record 
and  separators 
precede  it. 

4 

record  1 

exhausted 
(i.e.  FIELD3 
has  been  pro¬ 
cessed  already) 

»4» 

3 

SEP  is  the  FNBS  in 
the  remainder  (after 
FIELDS)  of  the  recorc 

5 

record 

exhausted 

2 

blank 

4 

no  records  remain  so 
it  is  not  meaningful 
to  request  the  FNBS 
after  the  next  field 

6 

FIELD3 

2 

•*4  * 

5 

FFIN2  examines  the 
remainder  of  the 
record  for  the  FNBS 

FFGET 

FFGET  will  return  options  and  current  conditions  for  the 
FFIN2  programs.  The  calling  sequence  is: 

SUBROUTINE  FFGET ( I0PT , LOPT ,NOPT , COPT , NCR) 

IOPT  is  the  option  code  input  by  the  user  and  has  one  of  the 
following  values. 


-3 
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1  -  return  output  file  number 

2  -  return  echo  file  number 

3  -  return  error  processing  flag  (0-  interactive, 

1  -  batch) 

4  -  return  numeric  field  validity  checks  (0  -  on,  1  -  off) 

5  -  return  quote  character 

6  -  return  line  terminator  character 

7  -  return  the  number  of  separator  characters 

8  -  not  used  (return  with  no  action) 

9  -  return  the  Hollerith  character  count 
10  -  return  input  record  length  parameters 

(1)  -  number  of  columns  to  be  read 

(2)  -  number  of  columns  to  be  examined 


-1  -  return  all  separator  characters 

-2  -  return  the  column  position  in  the  buffer  of  the 

last  non-separator  (zero  if  the  buffer  is  empty) 

-3  -  return  the  column  position  of  the  first  character 
of  the  next  field  (zero  if  the  buffer  is  empty) 

(see  also  FFNEXT) 

-4  -  return  selected  separators.  See  LOPT  and  COPT. 

-5  -  return  the  file  number  of  the  file  last  read  from. 

LOPT  is  a  one  dimensional,  integer  array  to  hold  integer  ouptut 
values.  If  only  one  value  is  returned,  LOPT  may  be  dimensioned 
to  one.  For  IOPT=-4 ,  the  user  must  input  the  desired  separator 
numbers  in  LOPT.  For  example,  if  LOPT  (I)  =  2,  then  COPT  (I)  will 
equal  the  second  separator  on  return. 
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COFt  is  a  one  dimensional  character  array  to  hold  output 
characters.  It  needs  to  be  dimensional  to  only  one  if  the 
option  returns  only  one  character  value. 

N0P|T  and  NCR  are  the  number  of  elements  in  LOPT  and  COPT, 
respectively. 

IFFCH5 

IFFCHS  will  determine  if  a  particular  character  is  a  separa¬ 
tor.  The  calling  sequence  is: 

I 

!  FUNCTION  IFFCHS (CHS) 

CHS  is  a  character  value  on  input.  The  values  of  IFFCHS  are: 

IFFCHS  ■  0  -  if  the  first  character  of  CHS  is 

not  a  separator 

*  n  -  if  the  first  character  of  CHS  is 
separator  n. 

FFLNS 

FFLNS  will  reset  the  internal  pointer  to  the  last  non¬ 
separator  character  in  the  buffer  (sea  COMMON  variable  NFF) .  No 
action  is  taken  if  the  buffer  is  empty,  otherwise,  FFLNS  will 
examine  the  buffer  and  set  NFF  to  the  last  non-separator  charac¬ 
ter  position  in  the  buffer.  It  dcas  not  affect  the  pointer 
to  the  current  field. 
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SECTION  V 

FFIN2  INTERNAL  DOCUMENTATION 

The  internal  buffer  and  all  other  permanent  informa¬ 
tion  is  stored  in  two  labeled  COMMON  areas  called  FFCO.M 
and  FFCOMC. 

The  COMMON  Area 

The  variables  in  COMMON  and  their  usage  are  explained 
below. 

IFF  and  NFF  are  pointers  to  the  buffer  array  LINE.  LINE 
(IFF)  is  the  first  character  of  the  next  field  if  there  is  one 
in  this  record.  If  the  buffer  has  been  exhausted, then  IFF  = 
NFF  +  1.  LINE  (NFF)  is  the  last  available  non- separator 

character  in  the  record.  In  other  words,  it  is  the  last  data 

Ij  i 

character  of  the  last  field  on  the  card.  If  a  call  is  made 
to  an  FFIN2  program  requesting  input  and  IFF  >  NFF,  then  a 

new  record  is  read.  Otherwise,  the  next  field  on  the  existing 

I 

record  is  interpreted. 

IF1  and  IFL  are  pointers  to  the  most  recently  processed 
field  on  the  record  if  there  is  one.  LINE  (IF1)  is  the  first 
character  of  the  field  and  LINE  (IFL)  is  the  last  character. 

If  a  new  record  has  just  been  read,  IF1  =  IFL  =  0. 
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JECHO  is  the  echo  file  unit  number.  If  JECHO  <  0,  no 
echo  of  data  is  performed. 

JRDOLD  is  the  input  file  unit  number  from  the  last  call 
to  an  FFIN2  input  program.  A  call  to  an  FFIN2  input  program 
with  a  new  JRD  causes  the  buffer  to  be  cleared  and  forces 
reading  a  new  record  from  the  new  input  file. 

NCNT  is  a  counter  for  input  records.  If  the  echo  option 
is  on,  NCNT  is  printed  when  the  record  is  printed  on  the  echo 
file. 

TERROR  is  the  indicator  for  error  processing.  If 
IERROR  "  0,  interactive  operation  is  assumed.  If  IERROR  /  0, 
batch  error  processing  is  done. 

ICHK  is  the  indicator  for  numeric  field  validity  check¬ 
ing.  If  ICHK  <*  0,  fields  are  checked.  If  ICHK  /  0,  no 
checking  is  done. 

NSE?  is  the  number  of  separators  in  use. 

LTERM  is  the  current  line  :  terminator  character. 

LQUOT  is  the  ctirrent  quote  character. 

LBNK  is  the  blank  character. 

NOWCHR  is  the  current  Hollerith  character  count. 

NWRDS  is  the  number  of  words,  at  NOWCHR  characters  per 
word,  to  hold  MCOLRD  characters.  NWRDS  is  calculated  in  FFSET. 

NNSEP  is  the  length  of-  the  LSEP  array. 

LSEP  is  an  array  whose  first  NSEP  locations  contain  the 
current  separator  characters. 

LTEMP  is  a  CHARACTER  variable.  FFIN2  packs  the  fields 
from  LINE  into  LTEMP.  The  character  capacity  of  LTEMP  must 
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be  sufficient  to  hold  at  least  20  characters.  A  capacity  of 
MXCOL  characters  is  recommended. 


LNUM  is  an  array  which  holds  all  characters  that  are  valid 
in  a  numeric  field.  LWUM  is  used  primarily  when  1CHK  *  0. 

IPMT  is  a  CHARACTER  variable  which  holds  a  character  alpha¬ 
numeric  representation  of  a  format  statement  for  processing  FFA. 

LINE  is  the  buffer  array. 

MXCOL  is  the  length  of  the  array  LINE. 

MCOLRD  is  the  number  of  columns  that  are  read  from  the 
input  file. 

MCOLFF  is  the  number  of  columns  examined  by  FFIN2  for 
valid  data. 

PSEP  is  the  first  non-blank  separator  following  the  last 
field  processed.  Blank  if  none. 

FFIN2  Internal  Subprograms 

There  are  several  subprograms  internal  to  the  FFIN2  which 
the  user  normally  is  not  concerned  with.  These  are  described 
below. 

SUBROUTINE  FFPAC  is  callled  by  FFA,  FFL,  FFR,  FFD,  FFC, 
and  FFI .  On  return  from  FFPAC,  the  appropriate  field  is 
packed  into  LTEMP.  To  accomplish  this,  FFPAC  calls  subroutines 
FFPAC1 ,  FFPAC2 ,  and  FFPAC4 .  The  calling  sequence  is: 
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where :  .  \ 

,  ,  ;i 

| 

1 

NCODE  *  identifier  for  calling  program  | 

.  i 

] 

1  -  PFA  | 

2  «  FFL  I 

3  -  FFD 

4  «  FFR  t 

.  i 

5  -  FFI 

6  -  FFC 

JRD  *  input  file  number. 

SUBROUTINE  FFPACl  processes  new  records.  If  a  current 
record  is  exhausted  (IFF.GT.NFF)  then  a  new  record  is  read 
and  examined  to  set  IFF  and  NFF  properly.  If  the  current 
record  is  not  exhausted,  an  immediate  RETURN  is  executed. 

In  either  case,  on  return,  LINE  (IFF)  is  the  first  character 
of  the  next  field,  and  LINE  (NFF)  is  the  last  character  of 
the  last  field  of  the  current  record.  The  calling  sequence 
for  FFPACl  is: 

SUBROUTINE  FFPACl  (JRD) . 
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SUBROUTINE  FFPAC2  will  delineate  the  next  field.  The 
calling  sequence  is:  j 

SUBROUTINE  FFPAC2  (IFRST,  I LAST,  JRD) 

where 

IFRST  -  on  return,  LINE  (IFRST)  is  the 

first  character  (not  a  quote) 
of  the  next  field. 

I LAST  -  on  return,  LINE  (ILAST)  is  the 

last  character  (not  a  quote)  of 
the  next  field. 

JRD  -  input  file  number. 

Also,  FFPAC2  will  reset  IFF  to  point  to  the  first  character  of 
the  field  following  the  one  delineated  by  IFRST  and  ILAST.  If 
there  is  none,  then  IFF  will  be  set  to  NFF  +  1  so  that  the 
next  call  to  FFPACl  will  cause  a  new  record  to  be  read. 

SUBROUTINE  FFPAC3  performs  standard  error  processing. 

The  calling  sequence  is: 


SUBROUTINE  FFPAC3  (*IPRT,  "XI ,~  12 ,  JRD) 


i 
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■1 

! 

{ 

■;  ■  j 

IPRT  -  l*prompt  for  bad  field,  2=do  not  prompt  \ 

11  -  LINE  (II)  is  the  first  character  of  an  ] 

| 

erroneous  field.  f 

-  .  j 

12  -  LINE  (12)  is  the  last  character  of  an  ! 

1  j 

i  erroneous  field.  i 

s  •  •  I 

|  JRD  -  input  file  number. 

|  FFPAC3  will  print  the  current  record  and  underline  the  bad 

field  on  the  output  file  and  the  echo  file  (if  one  exists).  i 
If  batch  error-processing  is  in  effect,  a  STOP  statement  will 

o  j' 

be  executed.  Otherwise,  if  IPRT  *  1  the  user  will  be  asked 

L  to  re-enter  the  erroneous  fields.  If  IPRT  “2  no  prompt  will 

p  be  issued.  This  feature  is  for  users  who  may  wish  to  call 

3  FFPAC3  directly.  See  Section  IV  for  such  applications. 

( 

.  SUBROUTINE  FFPAC4  will  pack  the  field  into  LTEMP. 

|  The  calling  sequence  is: 

SUBROUTINE  FFPAC4  (IFRST,  I LAST,  NCODE ,  JRD) 

i 

y  i 

where ! 

IFRST  and  I  LAST  =  values  set  by  FFPAC2 

NCODE  »  identifier  for  calling 
program  (see  FFPAC) 

JRD  =  input  file  number. 

For  alphanumeric  fields,  the  field  is  packed  up  to 
132  characters  starting  at  the  left.  Any  excess 
is  discarded  with  no  error  message.  For  logical  fields,  only 

I 
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the  first  non-blank  character  is  packed  into  LTEMP.  Twenty 
characters  are  packed  for  numeric  fields.  Leading  blanks  are 
filled  .if  the  field  is  less  than  20  characters,  and  an  error 
is  generated  if  a  numeric  field  has  more  than  20  characters. 

SUBROUTINE  FFPAC5  checks  logical  and  numeric  fields  for 
errors.  The  calling  sequence  is: 

SUBROUTINE  FFPAC5  (NCODE ,  IFRST ,  I LAST,  ICOND) 

where 

NCODE  *  identifier  for  calling  program 
(see  FFPAC) 

IFRST  and  I LAST  -  values  set  by  FFPAC2 

ICODE  =  0  if  the  field  is  acceptable 
1  if  the  fiel3  has  errors. 

FFPAC5  is  called  for  all  calls  from  FFL.  The  first  non-blank 
character  of  the  field  is  checked  to  determine  if  it  is  a 
"T"  or  "F."  If  not,  ICOND  =  1  is  returned. 

FFPAC5  does  validity  checking  for  numeric  fields  and  is 
called  for  this  application  only  if  ICHK  *  0. 

SUBROUTINES  FFLOAt^}  load  an  array  with  a  single  value. 

The  calling  sequence  is : 

SUBROUTINE  FFL0A{£) {LARRY ,  N,  ICHAR) . 

On  return,  the  first  N  words  of  the  one  dimensional  array  LARRY 
are  equal  to  ICHAR.  LARRY  and  ICHAR  are  integer  for  FFLOAD 
and  character  for  FFLOAC . 
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SECTION  VI 

CHANGES  NEEDED  TO  RUN  ON  OTHER  COMPUTER  SYSTEMS 

The  FFIN2  programs  are  written  in  ANSI  FORTRAN  77  (see 
FFA  for  the  only  exception) .  No  changes  should  be  required 
to  run  on  any  compiler  which  supports  FORTRAN  77. 

The  control  data  FTN5  (FORTRAN  77)  compiler  does  not 
process  the  END  parameter  cu  READ  statements  in  the  usual 
manner.  On  non-CDC  systems,  delete  the  statement  X  ■  EOF ( JRD) 
from  SUBROUTINE  FFPACl. 
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MOPAES  Terminology 


AIR  DEFENSE  SYSTEM 


A  component  of  Air  Defense  vhich  includes 
equipment  and  operators  and  for  vhich 
technical  and  tactical  training  are  recnirei. 
Examples  are  IHArJK  and  the  AH/TSQ-73. 


AIR  DEFENSE  SYSTEM 
MODULE  (ADSM) 


Models  of  operator  actions  and  equipment 
characteristics  for  Air  Defense  Systems  in 
the  K0PAB3  software.  These  models  are  pre¬ 
pared  vith  the  SAINT  simulation  language. 
Air  Defense  System  Modules  include  the 
SAINT  model  and  all  oata  needed  to  com¬ 
pletely  define  task  element  times,  task 
sequencing  requirements,  and  human  factors 
influences. 


AIR  SCENARIO 


A  spatial  and  temporal  record  of  aerial 
activities  and  characteristics  of  an  arr 
defense  "battle.  The  Air  Scenario  includes 
aircraft  tracks,  safe  corridors,  EC-!,  and 
other  aircraft  end  airspace  data.  See 
also  Tactical  Scenario. 


BRANCHING 


A  term  used  in  the  SAINT  simulation  lang¬ 
uage  to  mean  the  process  "by  which  TASK  nodes 
are  sequenced.  At  the  completion  of  the 
simulated  activity  at  a  TASK  node,  the 
Branching  from  that  node  determines  vhich 
TASK  nodes  will  "be  simulated  next. 


DATA  BASE  CONTROL 
SYSTEM 


That  part  of  the  M0PAD3  software  which 
performs  all  direct  communication  vith  the 
KOPAES  Data  Base.  All  information  transfer 
to  and  frem  the  data  "base  is  performed  "by 
invoking  the  subprograms  which  make  up  the 
Bata  Base  Control  System. 


DATA  SOURCE 
SPECIALIST 


A  specialist  in  obtaining  and  interpreting 
Army  documentation  and  other  data  needed  to 
prepare  Air  Defense  System  Modules. 
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EHVIRONKCrTAL  As  element  of  an  Environmental  State 


STATE  VARIABLE 

Vector. 

ENVIRONMENTAL 

STATE  VECTOR 

An  array 
or  charac 
than  one 
tal  Star* 
curing  a 
changes  i 

_ 

of  values  representing  conditions 
teristics  that  nay  affect  more 
operator.  Elements  of  Envircrmen - 
Vectors  may  change  dynamically 
KOPADS  simulation  to  represent 
.n  the  environment  conditions. 

KODERATOR  FUNCTION 

A  mathematical/logical  relationship  which 
alters  the  nominal  time  to  perform  an  ooera- 
tor  activity  (usually  a  Task  Element).  The 
nominal  time  is  changed  to  represent  the 
operator's  capability  to  perform  the 
activity  based  on  the  Operator’s  State 
Vector.  ' 

KOPADS  DATA  BASE 

A  eemputeriaed  data  base  designed  specifi¬ 
cally  to  support  the  KOPADS  software.  The 
KOPADS  Data  Base  contains  Simulation  Data 
Set(s).  It  communicates  interactively  with 
KOPADS  Users  during  prs—  and  post-run  data 
specification  and  dynamically  with  the  3AIDT 
software  during  simulation. 

i 

KOPADS  MODELER 

An  analyst  who  will  develop  Air  Defense 
System  Modules  and  modify/ develop  the 

KOPADS  software  system. 

i 

MONADS  USER 

An  analyst  who  will  design  and  conduct  simu¬ 
lation  experiments  with  the  KOPADS  software. 

MSAIKT  The  varient  of  SAUTT  used  in  the  KOPADS 

(KOPADS/S  AIN'T)  system.  The  standard  version  of  SAHIT  has 

been  modified  for  KOPADS  to  permit  share¬ 
able  subnetworks  and  more  sophisticated 
interrupts.  The  terns  SAUPP  and  KSAUTT  are 
used  interchangeably  when  no  confusion  will 
result.  See  also,  SAU3T. 


OPERATOR  STATE 
VECTOR 


An  array  of  values  representing  the  condi¬ 
tion  end  characteristics  of  an  operator  of 
an  Air  Defense  System.  Many  values  of  the 
Operator  State  Vector  viU  change  dynamically 
during  the  course  of  a  MOPADS  simulation  to 
represent  changes  in  operator  condition. 


OPERATOR  TASK 


An  operator  activity  identified  cur 
weapons  system  front-end  analyses. 


The  underlying  computer  simulation  language 
used  to  model  Air  Defense  Systems  in  Air 
Defense  System  Modules.  SAICT  is  an  acronym 
for  Systems  Analysis  of  Integrated  Networks 
of  Tasks.  It  is  a  well  documented  language 
designed  specifically  to  represent  human 
factors  aspects  of  man /machine  systems. 

See  also  MSAIST. 


SIMULATION  DATA  SET 


The  Tactical  Scenario  plus  all  required 
simulation  initialization  End  other  expuri 
cental  data  needed  to  perform  a  MOPADS 
simulation. 


SIMULATION  STATE 


At  any  instant  in  time  of  a  MOPADS  Simula 
tioa  the  Simulation  State  is  the  set  of 
values  of  ill  variables  in  the  MOPADS  sof 
ware  and  the  MOPADS  Data  Base. 


SYSTEM  MODULES 


See  Air  Defense  System  Modules 


The  Air  Scenario  plus  specification  of 
critical  assets  and  the  air  defense  con¬ 
figuration  (number,  type  and  location  of 
veanons  and  the  command  and  control  system) 


TACTICAL  SCENARIO 


TACTICAL  SCENARIO 
COMPONENT 


An  element  of  a  Tactical  Scenario,  e.g. , 
if  a  Tactical  Scenario  contains  several 
Q-73's,  each  one  is  a  Tactical  Scenario 
Component. 


See  Operator  Tank. 


TASK  ELEMENTS 


Individual  operator  actions  vhich,  vhen 
grouped  appropriately,  make  up  operator 
tasks.  Task  elements  are  usually  repre¬ 
sented  "by  single  SAH3T  TASK  nodes  in  Air 
Defense  System  Modules. 


TASK  NODE 


A  modeling  symbol  used  in  the  SAXKT  si 
tion  language.  A  TASK  node  represents 
activity;  depending  upon  the  modeling 
cunstances,  a  TASK  node  may  represent 
individual  activity  such  as  a  Task  Element, 
or  it  may  represent  an  aggregated  activity 
such  as  an  entire  Operator  Task. 


TASK  SEQUENCING 

MODERATOR 

FUNCTION 


A  mathematical/logical  relationship  vhich 
selects  the  next  Operator  Task  vhich  an 
operator  vill  perform.  The  selection  i3 
based  upon  operator  goal  seeking  character¬ 
istics. 


Additional  Terminology  and  Abbreviations 


TD1,  TD2 


Battalion 

AN/TSQ-73 

Tactical  Director 

Tactical  Director  Assistant 

The  operator  of  a  Battalion  AN/TSQ-73 


Hzl 


w&sm*. 
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I.  OVERVIEW  OF  THE  MOPADS  MODEL 


This  report  documents  the  implementation  details  of  the  IHAWK 
system  module.  It's  intended  audience  is  the  MOPADS  modeler, who 
must  maintain  and  explain  the  model.  A  companion  report  (Goodin  & 
Polito  (1983))  provides  user  information  for  the  MOPADS  user. 

The  MOPADS  operator  tasks  are  modeled  with  subnetworks  of 
MSAINT  task  nodes.  Each  node  has  a  subroutine  of  user  code  asso¬ 
ciated  with  it  where  the  user  may  write  code  to  access  the  data 
base  and  modify  the  MSAIHT  data  structure.  These  task  node  sub¬ 
routines  are  named  according  to  the  task  node  they  represent.  For 
instance,  the  subroutine  used  to  process  logic  associated  with  node 
175  is  named  T175Q  (T175G  is  Group  Q-73)  and  the  one  for  node  62  is 
named  T62Q  (T62G  if  Group  Q-73). 

The  two  operators  in  the  Group  Q-73  and  the  two  operators  in 
the  Battalion  Q-73  perform  various  tasks  in  the  networks.  The  Croup 
Q-73  network  is  a  subset  of  the  Battalion  Q-73  network.  The  Group 
Q-73  operators  perform  some  of  the  same  operator  tasks  as  the 
Battalion  Q-73  TD  (Tactical  Director)  operator.  The  operators  in 
the  Group  Q-73  will  do  al]  their  communications  with  themselves  and 
their  Battalion  Q-73.  A  Group  Q-73  will  not  communicate  with  a 
Battalion  Q-73  that  it  is  not  controlling.  The  Battalion  Q-73  will 
communicate  with  the  Group  Q-73  controlling  it  and  the  fire  units 
under  its  control.  This  communication  is  carried  out  by  sending 
messages,  altering  the  data  base,  altering  the  data  st-ucture,  or 
signaling  (clearing  an  operator  from  one  task  node  to  another). 

Table  1-1  is  a  list  of  some  of  the  assumptions  made  in  con¬ 
structing  the  MOPADS  model  of  the  Battalion  and  Group  Q-73's. 
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Table  1-1.  Assumptions. 

Jamming  and  ECK  are  not  considered. 

All  setup,  checkout  and  emplacement  procedures  have  been 
perfo-med, 

-  The  Q-73  will  not  be  mobile  during  the  simulation. 

All  ADP's  remain  operational  assuming  the  Q-73  has  not 
been  destroyed. 

The  ATDL  data  link  is  used  for  communicating  with  other 
AN/TSQ-73s  and  the  Q-73 ’ s  fire  units. 

7.  a  TDA  will  perfoim  all  IFF  procedures. 

A  target  will  be  positively  identified  if  the  TDA 
performs  IFF  procedures  on  that  target. 

The  CEASE  FIRE  command  will  not  be  modeled. 

TD  will  make  all  assignments  to  fire  units. 

All  Battalion  Q-73s  will  have  one  TDA  operator  and 
one  TD  operator. 

All  Group  Q-73s  will  have  two  TD  operators. 

When  a  Battalion  Q-73  identifies  a  target  the 
information  is  sent  to  all  its  fire  units. 


II,  MODEL  DESCRIPTION  FORMS 


1-0  ENTITIES 

The  operators  that  perform  the  work  in  the  Battalion  and 
Group  Q-73's  are  the  entities  in  their  respective  system  modules. 
The  forms  in  this  seciton  describe  each  entity,  their  attributes, 
and  their  resource  requirements. 


# 


W-ll 


I 


H 

<s 

s 


2- 0  RESOURCES 

There  were  no  MSAINT  resources  used  in  modeling  the  Battalion 
and  Group  Q-73's. 

3- 0  VARIABLES 

The  forms  in  this  section  describe  all  the  state  variables, 
system  attributes ,and  user  variables  used  in  the  Q-73  system 
modules.  Table  II -1,  shown  after  the  forms,  expands  the  definition 
for  the  variable  TSVALQ.  Note  that  no  state  variables  or  system 
attributes  are  used  in  the  Q-73  modules. 


VARIABLE  DEFINITION  AND/OR  DEFINING  EQUATION  INITAl  COMMON  BLOCK 

VALUE  (USER  VARIABLES  ONLY) 


4-0  TASK  NETWORKS 

In  this  section  are  the  forms  used  to  document  each  of  the 
operator  tasks  and  each  individual  noae  in  those  tasks.  Each 
operator  task  is  documented  by  tvo  types  of  forms:  MSAINT  TASK 
MODELS  and  MSAINT  TASK  NETWORKS .  The  MSAINT  TASK  MODEL  forms 
given  a  written  description  of  the  activities  involved  at  each 
node  on  the  network.  The  MSAINT  TASK  NETWORKS  forms  contain  the 
MSAINT  subnetworks  used  to  describe  each  operator  task.  Following 
these  tvo  forms  for  each  task  is  the  TASK  NODE  SPECIFIC  DATA  forms 
for  each  node  in  the  operator  task  (MSAINT  subnetwork).  These 
forms  contain  the  information  stored  in  the  data  base  for  each 
node. 

Note  that  the  source  nodes,  the  dead  node,  and  the  task 
sequencing  subnetwork  are  also  contain-. d  in  this  section.  These 
particular  nodes  are  not  shown  or.  the  MSAINT  TASK  MODEL  fonts 
because  there  are  no  operator  actions  involved. 

Note  that  some  of  the  task  nodes  and  task  numbers  ere  speci¬ 
fic  to  the  Battalion  Q-73  (denoted  by  (Ell)  after  the  number),  and 
some  are  specific  to  the  Group  Q-73  (denoted  by  (GRP)  after  the 
number) . 


Table  II-2,  at  the  end  of  this  section,  is  a  cross-reference 
table  that  may  be  used  to  look  up  which  operator  tasks  are  asso¬ 
ciated  with  which  nodes. 
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Table  II-2. 


CROSS  REFERENCE  OF  NOLE  NUMBERS  TO  OPERATOR  TASK  IIUJ-23ERS 

FOR 

AS/TSQ-73  SYST3-!  MODULE 

MSAIIJT 

NODE 

irjMBER 

TASK 

LABEL 

OPERATOR 

TASK 

NUMBER 

KSAIST 

NODE 

NUMBER 

TASK 

LABEL 

OPERATOR 
TASK  ' 
NUMBER 

1 

IDLETIME 

1 

40 

jSUIACT 

3 

2 

CANC2ND 

2 

41 

CMNCODE 

3 

3 

SENDTM 

3 

42 

ENDTSK3 

4 

4 

CLRHES 

4 

43 

DTHESDB 

4 

5 

PERFHOOK 

5 

44 

CLRHFE 

4 

6 

45 

CLRSTS 

4 

7 

CHIDFT 

7 

4G 

ENDTSK4 

4 

8 

INTTAP 

8 

47 

P0SH00K 

5 

9 

48 

NUWOOK 

5 

10 

SNDCOMM 

10 

49 

HOOKBRCH 

5 

11 

50 

HKR0UT1 

5 

12 

51 

HKR0UT2 

5 

13 

52 

PPOSHK 

5 

14 

53 

HKR0UT3 

5 

15 

ASSWEAPN 

15 

HOOKBRCH 

16 

54 

17 

55 

18 

56 

19 

57 

20 

RECCMD 

20  . 

58 

21 

59 

22 

DETALERT 

22 

60 

23 

61 

24 

62 

ENTC 

7 

25 

63 

ENT  ID 

7 

26 

DETMSGN 

26 

64 

27 

65 

28 

66 

DETM4 

8 

29 

67 

ENTMODE 

8 

30 

TASKSEQ 

30 

68 

31 

CRFATETO 

- 

69 

32 

CREATTDA 

70 

PRINT6 

8 

CREATTD2 

71 

PRM4CH 

8 

33 

72 

(ENDTSK8 

8 

34 

73 

35 

74 

36 

CANCL2 

2 

75 

3ETGENSP 

10 

37 

GENSPC 

3 

76 

INTSFUA 

10 

38 

ENTSAD 

3 

77 

39 

SWICMD 

3 

78 
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Table  II-2  (continued) 


CROSS  REFERENCE  OF  NODE  NUMBERS  TO  OPERATOR  TASK  NUMBERS 

FOR 


AN/TSQ-73  SYSTEM  MODULE 


NODE 

NUMBER 

TASK 

LABEL 

OPERATOR 

TASK 

NUMBER 

KSAEfr 

NODE 

NUMBER 

TASK 

LABEL 

OPERATOR 

TASK 

NUMBER 

79 

ENTCCC 

10 

119 

80 

120 

81 

121 

82 

122 

83 

123 

84 

124 

85 

125 

86 

126 

87 

127 

88 

128 

89 

129 

90 

DEADN0DE 

130 

91 

131 

92 

132 

93 

133 

94 

134 

95 

PRAARECM 

15 

135 

96 

H00KADR 

15 

136 

97 

ENTADRSS 

15 

137 

98 

SW0RCCEN 

15 

138 

99 

PRSADLDT 

15 

139 

100 

PRSASSN 

15 

140 

WHFUALRT 

22 

101 

PRSAPPR 

15 

141 

102 

ENDTSK15 

15 

142 

ALERT16 

22 

103 

143 

ALERT1 

22 

104 

144 

ENDTSK22 

22 

105 

145 

ALERT20 

22 

106 

146 

ALERT93 

22 

107 

147 

108 

EXMALERT 

20 

148 

109 

PRSCLRA 

20 

149 

110 

ENTCOMCO 

20 

150 

111 

ENDTSK20 

20 

151 

112 

152 

113 

153 

114 

154 

115 

155 

116 

156 

117 

157 

118 

158 

— 

.4  1  *  < 

C*-vX  / 


W-l  24 


Table  II-2  (continued) 


CROSS  REFERENCE  OF  NODE  NUMBERS  TO  OPERATOR  TASK  NUMBERS 

FOR 

AN/TSQ-73  SYSTEM  MODULE 


MSAiirr 

NODE 

number 


TASK 

LABEL 

RECMSG17 

RECMSG11 

ENDTSDK26 


OPERATOR 

TASK 

NUMBER 


KSAINT 

NODE 

NUMBER 


TASK 

LABEL 


OPERATOR 

TASK 

NUMBER 


TSEQTD 

T5EQTDA 

TDR0UTE1 

TDR0UTE2 

TDAR0UT1 

TDAR0UT2 


b-o  USER  FUNCTIONS 

There  ore  no  user  functions  in  the  Battalion  or  Croup  Q-73 
user  code. 

6- 0  MODERATOR  FUNCTION 

There  is  only  one  moderator  function  (referred  to  as  Mod¬ 
erator  Function  #l)  used  by  the  Q-73  systan  modules.  This  mod¬ 
erator  function  allows  the  user  to  gain  access  to  the  human  factors 
codes  for  moderating  task  performance  time. 

Any  task  node  that  has  moderator  function  one  active  must 
have  skills  and  distribution  data  stored  in  the  data  base,  and 
the  task  time  on  the  Task  data  card  must  be  specified  as  DS,1. 

7- 0  MESSAGES  SENT  FROM  Q-73  SYSTEM  MODULE 

The  following  forms  describe  each  of  the  messages  sent  from 
operators  in  the  .  attalion  and  Group  Q-73  system  modules  to  opera¬ 
tors  within  the  Q-73's  and  to  operators  in  the  IHAWX. 


»mwiw^ 

i". •-'*•< 


k\V. 


£3 


MDPADS  MESSAGE  DESCRIPTION 


Message  No.  l 

MESSAGE 

ID  ELEMENT 

Page  1  of  2 

Element 

Description 

Value 

t 

*  Receiver  CRN 

«. 

2 

Operator  Type 

1  or  3 

3 

Functional  Type 

1 

A 

Message  Subtype 

1 

5 

Message 

Priority 

-9 

MESSAGE  DATA  LINK  ELEMENT 

Sjfnsut 

Inscription 

ValiLS 

J 

Connumcation 

Network 

1-Voice 

2-ATDL 

2 

2 

Aeknowledgenent  Required 

1  -  Yes 

2  -  No 

1 

3 

Unused 

- 

A 

ATDL  Code  (Unused) 

- 

5 

*  Tine  Message  Gent 

- 

6 

*  Message 

Nunber 

- 

7 

*  Sender  CRN 

- 

8 

Sender  Operator  Type 

1 

? 

Sender  Systen 

Module  Type 

2  or  3 

10 

Task  Node  Nunber  Sent  Fron 

- 

«  Must  be  set  at 

the  tine  the  nessage  is  sent 

VARIABLE  MESSAGE  FORMAT 

Element 

Description 

•» 

if  Subs 

.  WORDS  =  U 

fc- 

Which 

Fire  Section(=l 

F.S.A,  =2  F.S.B,  = 

3  Both) 

3 

NT RACK 

Column  Number 

b 

NTRACK 

Column  Number  (use  only  if  element  2  =  3)  1 

5 

Copy  Row  if  of  FS 

MESSAGE 

SUBTYPE  DESCRIPTION 

Hold 

Fire  Command.  Tells  receiver  to  stop  engaging  an  air- 

craft  and  destroy  any  in-flight  missiles. 

Nane:  Riley  Goodin 

Systen  Module:  AN/TSQ-73 

Date:  2 

.2/20/83 

Project:  MOPADS 

F  ron 

To 

Fron 

To 

GRP( 3) 

BN(U) 

“  bn( 57 

HAWK( 35 ) 

fe 

[■hot 

m 

tjS£ 


MM  BS  MESSAGE  BESCSIPTICN 


Message  N 

o.  3  MESSAGE  lb  ELEMENT 

Page  1  efl 

LLsaui 

Bescnptioe 

Valve 

i 

e  Receiver  CRN 

- 

2 

Operator  Type 

1  cr  3 

3 

functional  Typo 

1 

4 

Message  Subtype 

3 

'i 

Message  Priority 

-7 

MESSAGE  BATA  LINK  ELEMENT 

ill212± 

1 


It  jmmiia 

Connumcation  Network 
1-Voice  2-ATDL 

Acknowledgment  Required 
1  -  le*  2  -  Na 

Unused 

ATDL  Codf  (Unused) 

Tint  Amd^i  Srnt 
Message  Munoer 
Sender  CRN 

Sender  Operator  Type 
Sender  Syste*  Module  Type 
Task  Node  Nunber  Sent  Fron 


Mitt 


1 

2  or  3 


•  nust  be  set  at  the  tine  the  nessage  is  sent 


LLtaiai 


VARIABLE  MESSAGE  FORMAT 


#  WORDS  =  U 

Which  Fire  Section  (=1  A,  =2  B,  =3  Both) 

NTRACK  Column  Number 

I, TRACK  Column  Number  =  2nd  F.S.  (if  element  2=3) 
Copy  Row  H  of  FS 


MESSAGE  SUBTYPE  DESCRIPTION 

Cease  Engage  Command.  Stop  engaging,  don't  destroy 
in-flight  missiles,  and  break  the  IHIPIR  lock. 


Nane:  Riley  Goodin 

12/20/83 


Systen  Module:  AN/TSQ-T3 
Project:  M0PADS 


Fron 

To 

GRP( 3) 

BN(U) 

BM(  3) 

HAWK( 37 ) 

28 


NOT  ACS  MESSAGE  DESCRIPTION 


ktiiitt  Ms.  j. 


£le«**t 


MESSAGE  1)  ELEMEMT 


IllLLUlm 

•  littivtr  CBM 
Operator  Type 
functional  Type 
mi»f»  Subtype 
ftessaye  Priority 


MESSAGE  DATA  LINK  ELEMEMT 


Ituml  8  ?a 

Connuntc ation  network 
1-Voue  2-ATDL 

Acknowledgement  Required 

1  -  let  2-1*0 

llauitd 

ATDL  Code  (Unused) 

•  Tine  Message  Sent 

•  )less>9e  ftunbrr 

•  Seroer  CRH 

Sender  Operator  Type 
Sender  System  Module  Type 
Task  Node  Number  Sent  From 


*  Must  be  set  at  the  tine  the  message  is  sent 


VARIABLE  MESSAGE  FORMAT 


LUftSSA  Inscription 

1  #  WORDS  =  2 

2  Which  Fire  Section  (=1  A,  =2  B) 

3  NTRACK  Column  Pointer 


*••5*  i  ef  i 


tiXMS 


1  or  3 
1 
k 

♦ 6 


Value 

2 

1 


1 

2  or  3 


MESSAGE  SUBTYPE  INSCRIPTION 

Engage  Command  on  a  track  which  was  previously  assigned 
(covered).  Gives  permission  to  fire. 

(Coupled  with  Message  26  to  Q-73) 


Nane:  Riley  Goodin 
bate:  12/20/83 


Systen  Module: 
Project: 


AN/TSQ-73 

MOPADS 


Fron 

To 

b:j(io) 

HAWK( 32 ) 

tun)'  ho 


LLtaai 


r  t 


1 


IturABS  MESSAGE  CrSCRIPTION 


MESSAGE  IB  ILtrtENT 


>«Sfripti9» 

Vtlue 

•  Deceiver  CRN 

•» 

Operator  Type 

3 

Functional  Type 

1 

7 

Message  Priority 

♦ 6 

MESSAGE  DATA  LINK  ELEMENT 


'4*1211 

Connuni cation  network  | 

1-Voice  2-ATDL  f 

2 

Acknowledgment  Required 

1  -  tes  2  -  No 

1 

Unused 

— 

ATDL  Code  (Unused) 

_ 

•  Tine  Message  Sent 

•  Messase  Nunber 

- 

*  Sender  CRN 

- 

Sender  Operator  Type 

1 

Sender  Systen  Nodule  Type 

2  or  3 

Task  Node  Nunber  Sent  Fron 

- 

«  Must  be  set  at  the  tine  the  is  sent  * 


VARIABLE  MESSAGE  FORMAT 


Sljas.nl 


#  WORDS  =3  V  • 

Which  Fire  Section  (=0  Either,  =1  A,  =2  B) 
NTRACK  Column  Number 

=1  Primary,  =2  Secondary,  -1  if  covered 


MESSAGE  SUBTYPE  DESCRIPTION 
Assign-New  Tartet  -  HIPIR  Lock  do  not  fire 


Nane:  Riley  Goodin 

Date:  12/20/83 


S«'.ten  Module:  AN/TS^-73 
Project:  MOPADS 


Fron 


BH(15) 


To 


F  WK(  32 


noms  MESSAGE  DESCRIPTION 


Message  Ho.  6  MESSAGE  Hi  ELEMENT  P*f*  j  Of  j 


Liisni 

i 

n 

3 

1  4 

5 

• 

Receiver  CRN 

Operator  Type 
functional  Type 

Message  Subtype 

Message  Priority 

Value 

3 

1 

8 

♦5 

MESSAGE  DATA  LINK  ELEMENT 

Eif-r't 

f^srrjption 

Vitui 

Connunication  Network 

1-Voice  2-ATDL 

2 

2 

Acknouledoenent  Required 

1  -  les  2  -  No 

1 

3 

Unused 

4 

ATDL  Code  (Unused) 

5 

• 

Tine  Message  Sent 

6 

• 

Message  Runner 

7 

f 

Sender  CRN 

3 

5ender  Operator  Type 

1 

.  ? 

Sender  Systen  Module  Type 

2  or  3 

10 

Task  Node  nunber  Sent  Fron 

- 

♦  Must  be  set  at  the  tine  the  nessage  is  sent 

VARIABLE  MESSAGE  FORMAT 


Description 

l 

H  WORDS  =2 

2 

Which  Fire  Section  (=0 

Either,  =1  A,  =2  B) 

3 

NT RACK  Column  Number 

MESSAGE  SUBTYPE  DESCRIPTION 


Cover  New  Target  Command.  Obtain  a  HIPIR  lock  on  a  new 
target,  but  do  not  fire. 


Mane:  Riley  Goodin  5ysten  Module:  AN/TSQ-73 

Date:  12/20/83  Project:  MOPADS 


F  ron 

To 

Fron 

To 

BIT  (15) 

HAWK (33) 

— 

....  .  - 

*G?ASS  «SSA8£  KSaUPTlOM 


\ 

\ 


heseage  Ha.  11  i£SSA3£  it  ELEMENT  P»f*  i  *f  i 


£ir«f*t 

Initial 

V»lr* 

1 

•  fteceiver  CBN 

m 

2 

Operator  Type 

1 

3 

fractional  Type 

k 

4 

Message  Subtype 

1 

5 

Message  Priority 

♦2 

MCSSASC  BAT*  LINK  ELEMENT 


Llr*  tit 

iesrriptjofl 

Value 

1 

Connunicatioa  network 

1-Vcie*  2-ATBL 

2 

2 

Ac knowledge** at  Required 

1  -  Yes  2  -  Bo 

2 

3 

(loused 

4 

ATBL  Code  (Unused) 

M 

S 

•  Tine  Message  Sent 

m 

6 

•  Message  Nursber 

7 

•  Sender  CRB 

8 

Sender  Operator  Type 

1 

» 

Sender  Systen  Module  Type 

3 

10 

Task  Node  Rubber  Sent  Fro* 

•  Rust  be  set  at  the  tine  the  nessage  is  seat 


VARIABLE  ME5EAGE  FORMAT 


Lka,??l 

Description 

1 

#  WORCS  -  1 

2 

Message  Number  Acknowledging 

MESSAGE  SUBTYPE  DESCRIPTION 

Acknowledge  Message,  type  Will  Comply  (BN  to  GRP  only) 


None:  Riley  Goodin 

Date:  12/20/83 

Syiten  Module:  AN/TSQ-73 

Project:  MOPADS 

f  ros 

To 

Fron 

To 

BN (20) 

GRP( 26 ) 
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USER  WRITTEN  PROGRAMS 


1- 0  OY  EH  VIEW'  OF  THE  FLOW  OF  CONTROL 

The  user-written  code  for  the  Battalion  end  Croup  Q-73 
system  modules  are  accessed  via  the  subroutines  UTBNQ  and  OTGRPC, 
respectively.  When  a  node  is  being  processed,  MSAINT  calls  sufc- 
routin  UTASK,  UTASK  determines  if  it  is  a  Battalion  or  Croup 
Q-73  node.  If  so,  UTASK  calls  UTBHQ  or  UP.CRFG.  These  subrou¬ 
tines  then  call  the  subroutine  that  performs  processing  for  that 
node  (e.g.,  T10Q,  T15CQ,  etc.){Tl60C,  etc.  if  Croup). 

The  Q-73  KSAITIT  networks  regulate  the  flow  of  the  entitites 
through  the  task  nodes.  Branching  is  accomplished  either  deter¬ 
ministically  where  the  operator  follows  a  logical  sequence  of 
actions  or  conditionally  where  the  operator  may  do  one  node  verses 
another  node  depending  on  the  state  of  the  system. 

2- 0  EXTERNAL  FILE  USAGE 

There  is  no  direct  external  file  access  in  the  Battalion 
and  Group  Q-73  system  modules. 

3- 0  SUBPROGRAM  DESCRIPTIONS 

This  section  contains  a  copy  of  the  subprogram  descriptions 
for  each  of  the  Battalion  and  Group  Q-73  user  code  subprograms. 

These  subprograms  are  on  the  following  pages.  Only  four  subroutines 
are  specific  to  Group  Q-73*  They  are  INITG,  T160G,  Tl6lG,  and 
UTGRPG.  Since  the  operators  in  the  Group  Q-73  do  some  of  the  same 
tasks  as  the  operators  in  the  Battalion  Q-73  the  user  code  associated 
with  a  node  in  a  network  for  the  Battalion  may  be  used  for  the  same 
node  in  the  Group  Q-73. 
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SUBROUTINE  CLTDO  (IB) 


C 

C— MODULE!  HOPADS  BATTALION  A1/TSP-73  SYSTEM  NODULE 
C— REFERENCE!  HOP.'DS  VOLUME  S.I3 
C 

C**PURPOSE  t  THIS  SUBROUTINE  IS  USES  TO  COMPUTE  THE  SCREEN  CLUTTER  FOR 

C  A  0-73  OPERATOR. THIS  VALUE  IS  THEN  USED  TO  UPDATE  THE 

C  OPERATOR  STATE  VECTOR. 

I 

C**1NPUT  PARAMETERS!  ID-OPERATOR  IS 
C 


SUBROUTINE  6EV1Q(IDCPfNC0PI,I0PR,GSJ ) 

C— MODULE!  HOPADS  BATTALION  AN/TSQ-73  SYSTEM  MODULE 
C— REFERENCE!  HOPADS  VOLUME  S.13 
C— PURPOSE! 

C  BEV10  'JILL  EVALUATE  THE  GOAL  STATE  FOR  GOAL  I  FOR  THE 

C  AN/TSQ-73  OPERATORS.  THE  FIRST  60AL  IS  SELF  PRESERVAT10 

C— INPUT  PARAMETERS! 

C  IDOP-OPERATOR  ID 

C  NCOPI-COPY  ROU  NUMBER  OF  THE  OPERATOR'S  UNIT 
C— INPUT/OUTPUT  PARAMETERS! 

C  I0PR(2)-DBAA  OF  THE  OPERATOR 

C— OUTPUT  PARAMETERS! 

C  GS1-G0AL  STATE  FOR  GCAL  1.  IF  THE  OPERATOR  DOES  NOT  HAVE 
C  GOAL  1,  GS1  IS  UNCHANGED. 


SUBROUTINE  GEV2Q(ID0P,HC0PI,I0PR,G52> 

C—MODULE:  HOPADS  BATTALION  AN/TSQ-73  SYSTEM  MODULE 
C- -REFERENCE:  HOPADS  VOLUHE  5.15 
C- -PURPOSE: 

C  GEV20  UILL  EVALUATE  THE  GOAL  STATE  FOR  GOAL  2  FOR  THE 
C  AN/TSQ-73  OPERATORS.  THE  SECOND  GOAL  IS  TO  PROTECT  CRITICAL 

C  ASSETS. 

C--INPUT  PARAMETERS! 

C  IDOP-OPERATOR  ID 

C  HCOPI-COPY  ROW  NUMBER  OF  THE  OPERATORS  UNIT 

C— INPUT/OUTPUT  PARAMETERS! 

C  I0PR(2>-DBAA  OF  THE  OPERATOR 

C — OUTPUT  PARAMETERS: 

C  GS2-G0AL  STATE  FOR  GOAL  2.  IF  THE  OPERATOR  DOES  NOT  HAVE 
C  GOAL  2,  GS2  IS  UNCHANGED. 


SUBROUTINE  6EV30<IBOPtMCOPI,10P.<,B53> 

C--HODULE*  MOPADS  BA7TALIOM  AN/TSP-73  SYSTEM  MODULE 
C~ REFERENCE*  MOPADS  VOLUME  S.13 
C  -PURPOSE* 

C  GEV30  WILL  EVALUATE  THE  GOAL  STATE  FOR  GOAL  3  FOR  THE 
C  AN/TSO-73  OPERATORS.  THE  3-RD  GOAL  IS  REDUCE  THE  NUMBER  OF 

C  UNASSIGNED,  HOSTILE  TRACKS  CR  COVERED  TRACKS. 

C— INPUT  PARAMETERS* 

C  19DP-0PERAT0R  10 

C  NCOPI-COPT  RGU  NUMBER  OF  THE  OPERATOR'S  UNIT 

C— INPUT/OUTPUT  PARAMETERS* 

C  I0PR(2)-DIAA  OF  THE  OPERATOR 

C— OUTPUT  PARAMETERS* 

C  GS3-G0AL  STATE  FOR  60AL  3.  IF  THE  OPERATOR  DOES  NOT  HAVE 
C  60AL  3,  6S3  IS  UNCHANGED. 


SUBROUTINE  GEV4Q(IDOP,NCOPI,IOPR,GS4> 

C— MODULE*  MOPADS  BATTALION  AN/TSO-73  SYSTEM  NODULE 
C— REFERENCE:  MOPADS  VOLUME  5. IS 
C— PURPOSE* 

C  GEV4Q  WILL  EVALUATE  THE  GOAL  STATE  FOR  GOAL  4  FOR  THE 

C  AN/TSQ-73  OPERATORS.  THE  4-TH  GOAL  IS  REDUCE  THE  HUMBER  Or 

C  UNIDENTIFIED  TRACKS. 

C— INPUT  PARAMETERS* 

C  IDOP-OPERATOR  ID 

C  MCOPI-COPT  ROU  NUMBER  OF  THE  OPERATOR'S  UNIT 
C— IHPUT/OUTPUT  PARAMETERS* 

C  I0PR(2)-DBAA  OF  THE  OPERATOR 

C— OUTPUT  PARAMETERS* 

C  GS4-G0AL  STATE  FOR  60AL  4.  IF  THE  OPERATOR  DOES  HOT  HAVE 
C  GOAL  4,  GS4  IS  UNCHANGED. 


SUBROUTINE  GEVSQ<IDOP,NCOPI ,IOPR,GS!i> 

C— MODULE*  HOPADS  BATTALION  AN/TSO-73  SYSTEM  MODULE 

C--REFERENCE*  MOPADS  VOLUME  5.15 

C--PURPQSE* 

C  GEV5Q  UILL  EVALUATE  THE  GOAL  STATE  FOR  GOAL  5  FOR  THE 
C  AN/TSO-73  OPERATORS.  THE  5-TH  GOAL  IS  RFDUCE  THE  NUMBER  OF 

C  VIDEO  CONTACTS. 

C — INPUT  PARAMETERS* 

C  IDOP-OPERATOR  ID 

C  NCOPI-COPY  ROU  NUHBER  OF  THE  OPERATOR'S  UNIT 
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C—  INPUT/OUTPUT  PARAMETERS!  ^ 
C  X0PM(2)-DIAA  OF  THE  OPERATOR  f> 
C— OUTPUT  PARAMETERS!  ^ 
C  0S5-G0AL  STATE  FOR  GOAL  5.  IF  THE  OPERATOR  DOES  HOT  HAVE  '*:> 

C  COAL  Sf  CSS  IS  UNCHANGED. 


SUBROUTINE  GEV60(ID0P,NC0PI,I0PRfBS4)  §\ 

C— MODULE:  MOPAOS  BATTALION  AN/TSO-73  STSTEM  MODULE 
C— REFERENCE!  MOPABS  VOLUME  5.15 

C— PURPOSE!  V* 

C  GEVAO  WILL  EVALUATE  THE  GOAL  STATE  FOR  GOAL  A  FOR  THE 

C  AN/TSO-73  OPERATORS.  THE  A-TH  GOAL  IS  MAXIMIZE  MISSILES. 

C— INPUT  PARAMETERS!  £■' 

C  IBOP-OPERATOR  IB  £ 

C  NCOPI-COPT  ROU  NUMBER  OF  THE  OPERATOR'S  UNIT 

C— INPUT/OUTPUT  PARAMETERS!  v. 

C  I0PR(2)-DBAA  OF  THE  OPERATOR  N 

C— OUTPUT  PARAMETERS! 

C  6SA-G0AL  STATE  FOR  GOAL  A.  IF  THE  OPERATOR  DOES  NOT  HAVE 

C  GOAL  A,  6SA  IS  UNCHANGED.  >' 

W 


SUBROUTINE  GEV70(ID0PtNC0Pl,I0PRfGS7) 

C— MODULE!  HOPAPS  BATTALION  AN/TSG-73  STSTEM  MODULE 
C— REFERENCE:  MOPAOS  VOLUME  5.15 
C— -PURPOSE! 

C  GEV7Q  WILL  EVALUATE  THE  GOAL  STATE  FOR  GOAL  7  FOR  TKE 

C  AN/TSQ-73  OPERATORS.  THE  7-TH  GOAL  IS  RECEIVE  MESSAGES.. 

C— INPUT  PARAMETERS! 

C  IDOP-OPERATOR  ID 

C  NCOPI-COPT  ROU  NUMBER  OF  THE  OPERATOR'S  UNIT 
C — INPUT/OUTPUT  PARAMETERS: 

C  I0PR(2)-DBAA  OF  THE  OPERATOR 

C-- OUTPUT  PARAMETERS: 

C  GS7-G0AL  STATE  FOR  GOAL  7.  IF  THE  OPERATOR  DOES  NOT  HAVE 
C  GOAL  7,  GS7  IS  UNCHANGED, 


SUBROUTINE  GEVSOt IBOP, NCOPI , IOPR , GSB ) 

C— MODULE:  MOPADS  BATTALION  AN/TSQ-73  SYSTEM  MODULE 
C — REFERENCE:  MOPADS  VOLUME  5.15 
C — PURPOSE: 

C  GEVSO  UILL  EVALUATE  THE  GOAL  STATE  FOR  GOAL  8  FOR  THE 

C  AN/TSQ-73  OPERATORS.  THE  8-TH  GOAL  IS  DO  NOT  SHOOT  AT  FRIENDS. 
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C— INPUT  PARAMETERS: 

C  IDOP-OPERATOR  IB 

C  NCOP1-COPT  ROU  NUMBER  OF  THE  OPERATOR'S  UNIT 

C— INPUT/OUTPUT  PARAMETERS: 

C  I OPR ( 2 > - DBA A  OF  THE  OPERATCR 

C— OUTPUT  PARAMETERS: 

C  0S8-GOAL  STATE  FOR  GOAL  8.  IF  THE  OPERATOR  DOES  NOT  HAVE 

C  COAL  8,  CSS  IS  UNCHANGED. 


SUBROUTINE  GEVALQ( IDOP, NADSM.NCOPI, NGS, ICPR.GS, NNG) 

C— MODULE:  MOPADS  BATTALION  AN/TSO-73  SYSTEM  MODULE 

DEREFERENCE:  MOPADS  VOLUME  3.15 

C-fPURPOSE: 

C  GEUALO  UILL  EVALUATE  AN  OPERATOR'S  GOAL  STATE  VECTOR 
Cl'  FOR  THE  AN/TSQ-73  BATTALION. 

C 

C—  INPUT  PARAMETERS:  j 

C  IDOP-OPERATOR  ID 

C  MADSH-SYSTEM  MODULE  TYPE 

C  NCOPI-CQPY  ROU  NUMBER 

C  NGS-ACTUAL  LENGTH  OF  65 

C— INPUT/OUTPUT  PARAMETERS: 

C  IQPT ( 2) -DBAA  OF  THE  OPERATOR  STATE  VECTOR 

C— OUTPUT  PARAMETERS: 

C  6S(HGS)-G0AL  STATE  VECTOR 

C  HNG-THE  NUMBER  OF  GOALS  THE  OPERATORS  OF  THE  SYSTEM  HAVE. 

C  (I.E.  ONLY  CHE  FIRST  NNG  ELEMENTS  OF  GS  HAVE  MEANINGFUL 

C  *  INFORMATION).  IF  THE  OPERATOR  DOES  HOT  HAVE  GOAL  I, 

C  THEN  GS(I>  — l.EIO. 


FUNCTION  IFFQ(IB,NTRK) 


C— MODULE:  MOPADS  BATTALION  AN/TSQ-73  SYSTEM  MODULE 
C--REFERENCE:  MOPADS  VOLUME  5.15 
C 

C**PURPOSEt  THIS  SUBROUTINE  IS  USED  TO  PERFORM  IFF  OPERATIONS  ON  A 
C  TRACK  FOR  THE  Q-73. 

C 

C**INPUT  PARAMETERS:  ID=OPERATOR  ID 

C  NTRKsNTRACK  COLUMN  NUMBER 

C 

C*»OUTPUT  PARAMETERS:  IFFQ=1  IF  HOSTILE 

C  =2  IF  FRIEND 

C  -3  IF  UNKNOUN 

C 
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FUNCTION  IFNODQ  UOPP) 

C 

C—MCDULE:  MOPADS  BATTALION  AN/TSO-73  SYSTEM  NODULE 
C— REFERENCE:  MOPADS  VOLUME  S.15 
C 

C**PURP05Et  THIS  SUBROUTINE  IS  USES  TO  DETERMINE  UHICH  IFF  MODE  SHOULD 
C  BE  SELECTED  IT  THE  TDA  IN  THE  Q-73. 

C 

C**1NPUT  PARAMETERS:  I0PP-0PERAT0R  ID 
C 

C**0UTPUT  PARAMETERS:  IFMODQ-1  CHANGE  TO  MODE  1,2, OR  3 
C  >2  REMAIN  IN  CURRENT  MODE 

C  >3  SELECT  MODE  4 

C 


SUBROUTINE  INITQ(NRUN) 

C— MODULE:  MOPADS  BATTALION  AN/TSQ-73  SYSTEM  MODULE 
C— REFERENCE:  MOPADS  VOLUME  5.15 
C— PURPOSE: 

C  INITQ  PERFORMS  INITIALIZATION  FOR  THE  BATTALION  AN/TSO-73 

C  SYSTEM  MODULE 

C— INPUT  PARAMETERS: 

C  NRUN-RliH  NUMBER 

C  O-DO  ONE-TIME  INITIALIZATION  BEFORE  ANY  RUNS 

C  N— INITIALIZE  FOR  RUN  N. 


SUBROUTINE  0EVALQ<ID0F,NADSH,NC0PI,GS,NN3,JTASK,I0PR,GSJ,TJ,*> 
C — MODULE:  MOPADS  BATTALION  AN/TSQ-73  SYSTEM  MODULE 
C--REFERENCE:  MOPADS  VOLUME  5.15 
C--PURPOSE: 

C  OEVALQ  UILL  COMPUTE  THE  EXPECTED  GOAL  STATE  VECTOR  FOR 
C  THE  AN/TSQ-73  OPERATORS. 

C — INPUT  PARAMETERS: 

C  IDOP-OPERATOR  ID 

C  NADSM-SYSTEM  MODULE  TYPE 

C  NCOPI-COPY  ROU  NUMBER 

C  GS(NNO)-CURRENT  COAL  STATE  VECTOR 

C  JTASK-OFERATOR  TASK  NUMBER  OF  THE  OFERATQR.  OEVALO  UILL 

C  EVALUATE  EXPECTED  GOAL  STATES  GIVEN  THAT  THE 

C  OPERATOR  PERFORMS  TASK  JTASK. 


v. 
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C — IHFUT/OUTPUT  PARAMETERS: 

C  I0PR(2)-DBAA  OF  THE  OPERATOR 

C  GSJ(NNG) -EXPECTED  GOAL  STATES  RESULTING  FROM  PERFORMING 
C  TASK  JTASK.  ON  INPUT,  BSJ*GS. 

C— OUTPUT  PARAMETERS: 

C  TJ-EXPECTED  TIME  (MINUTES)  TO  PERFORM  TASK  JTASK.  IF  THE 

C  OPERATOR  CANNOT  PERFORM  OR  DOES  NOT  PERFORM  TASK  JTASK, 

C  THEN  TJ—  1. 

C--ALTERNATE  RETURNS: 

C  1 -JTASK  IS  GREATER  THAN  THE  MAXIMUM  TASK  NUMBER  THAT  THE  OPERATOR 
C  PERFORHS.  OEVALQ  DILI  BE  CALLED  REPEATEDLY  UITH  GREATER 

C  VALUES  OF  JTASK  UNTIL  THIS  CONDITION  OCCURS. 


SUBROUTINE  0TS15Q(ID0P,NADSH,HC0PI,GS,NNG,I0PR,GSJ,TJ) 

C-- MODULE:  NOPADS  BATTALION  AN/TSQ-73  SYSTEM  MODULE 
C— REFERENCE:  MOPADS  VOLUME  5.15 
C— PURPOSE: 

C  0TS150  PERFORMS  EVALUATION  OF  OPERATOR  TASK  15  FOR  THE 
C  BATTALION  Q-73  OPERATORS.  OTSISQ  IS  CALLED  BY  OEVAL3  ONLY. 
C — INPUT  PARAMETERS: 

C  IDOP-OPERATOR  ID 

C  HADSM-SYSTEM  MODULE  TYPE 

C  HCOPI-COPY  ROU  NUMBER 

C  GS(NNG) -CURRENT  GOAL  STATE  VECTOR 

C— INPUT/OUTPUT  PARAMETERS: 

C  IOPR(2)-DBAA  OF  THE  OPERATOR 

C  GSJ(NNG) -EXPECTED  GOAL  STAGES  RESULTING  FROM  PERFORMING 

C  TASK  15.  ON  INPUT,  G3J=GS. 

C— OUTPUT  PARAMETERS: 

C  TJ-EXPECTED  TIME  (MINUTES)  TO  PERFORM  TASK  15.  IF  THE 

C  OPERATOR  »ANNOT  PERFORM  OR  DOES  MOT  PERFORM  TACK  15, 

C  THEN  TJ=-1 . 


SUBROUTINE  Q73EQCK0DE) 

C— MODULE:  MOPADS  BATTALION  AN/T3Q-73  SYSTEM  MODULE 
C — REFERENCE:  MOPADS  VOLUME  5.15 
C— INPUT  PARAMETERS: 

C  Q73EQ  PERFORMS  SPECIAL  ERROR  PROCESSING  FOR  MOPADS  ERROR 

C  CODES  5000-599?  UHICH  ARE  GENERATED  IN  THE  0-73  SYSTEM 

C  MODULE  CODE 

C — INPUT  PARAMETERS: 

C  KODE-ERROR  CODE  VALUE 


SUBROUTINE  T — Q  (NPLACE) 

C 

C~ NODULE!  MOPADS  BATTALION  AN/TSQ-73  SYSTEM  MODULE 
C--REFERENCE:  MOPADS  VOLUME  5.15 
C 

C**PURPOSE J  USER  CODE  FOR  BN  0*73  TASK  NODE  — 

C 

C**INPUT  PARAMETER:  NPLACE  -  TASK  OCCURRENCE  TINE 
C 

.  THIS  PROGRAM  IS  TYPICAL  OF  ALL  - 

NODE  SUBROUTINES 


FUNCTION  USERFQ(ICODE) 

C— MODULE:  MOPADS  BATTALION  AN/TSQ-73  SYSTEM  MODULE 

C — REFERENCE:  MOPADS  VOLUME  5.15 

C—PURPOSE: 

C  USERFQ  EVALUATES  THE  USER  FUNCTION  FOR  THE  6R0UP  AND 

C  BATTALION  PN/TSQ-73 

C — INPUT  PARAMETERS: 

C  ICODE-USER  FUNCTION  CODE 

C — OUTPUT  PARAMETERS: 

C  USERFQ-VALUE  OF  THE  USER  FUNCTION 


FUNCTION  USERNQf ICODE) 

C — MODULE:  MOPADS  BATTALION  AN/TSQ-73  SYSTEM  MODULE 

C — REFERENCE:  MOPADS  VOLUME  5.15 

C—PURPOSE: 

C  USERNQ  EVALUATES  THE  INPUT  USER  FUNCTION  FOR  THE  SKOUP  AND 

C  BATTALION  AN/TSO-73 

C— INPUT  PARAMETERS: 

C  ICODE-USER  FUNCTION  CODE 

C— OUTPUT  PARAMETERS: 

C  USERNQ-VALUE  OF  THE  USER  FUNCTION 
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SUBROUTINE  UTBNQ(NT,NPLACE) 

C — rtODULE ;  HOPADS  BATTALION  AN/TSQ-73  SYSTEM  MODULE 
C— REFERENCE:  HOPADS  VOLUME  5.15 
C— PURPOSE: 

C  UTBNQ  PROCESSES  CALLS  FROH  UTAS.!  FOR  THE  BATTALION  AN/TSQ-73 

C  SYSTEM  HODULE. 

C— INPUT  PARAMETERS: 

C  NT-TASK  NODE  NUMBER 

C  NPLACE-1 ASK  NODE  OCCURRANCE  TIME < SEE  UTASK) 


SUBROUTINE  lNITG(NRUN) 

C— PURPOSE: 

C  INITG  PERFORMS  INITIALIZATION  FOR  THE  GROUP  AN/TSQ-73 

C  SYSTEM  HODULE 

C— INPUT  PARAMETERS: 

C  NRUN-RUN  NUMBER 

C  O-DO  ONE-TIME  INITIALIZATION  BEFORE  ANY  RUNS 

C  N-IKITIALIZE  FOR  RUN  N. 
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SUBROUTINE  T160G  (NPLACE) 

C 

C 

C**PURPQSE :  USER  CODE  FOR  GROUP  Q-73  TASK  NODE  UO 
C 

C*»INPUT  PARAMETER:  NPLACE  -  TASK  OCCURRENCE  TIME 

C 


SUBROUTINE  T16JG  (NPLACE) 

C 

C 

C**PURPOSEt  USER  CODE  FOR  GROUP  Q-73  TAS.I  NODE  161 
C 

C**INPUT  PARAMETER:  NPLACE  -  TASK  OCCURRENCE  TIME 
C 
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SUBROUTINE  UTGRPG(NTf NPLACE) 

C— PURPOSE: 

C  U7GRPG  PROCESSES  CALLS  FROM  UTASK  FOR  THE  GROUP  AN/TSQ-73 

C  SYSTEH  MODULE. 

C— INPUT  PARAMETERS: 

C  NT-TASK  NODE  NUMBER 

C  HPLACE-TASK  NODE  OCCURRANCE  TIME ( SEE  UTASK) 
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l*-0  ERROR  PROCESSING 

When  an  error  involving  the  Q-73  user  code  is  detected  a 
call  is  made  to  subroutine  SERB.  The  only  parameter  this  sub¬ 
routine  has  is  the  error  code.  The  error  codes  5000  to  5999 
are  reserved  for  errors  detected  in  either  the  Group  or  Batta¬ 
lion  Q-73.  The  error  codes  5500  to  57^*9  are  reserved  for 
errors  solely  in  the  Grouo  Q-73.  The  error  codes  5750  to  5999 
are  reseved  fo:.*  errors  solely  in  the  Battalion  Q-73.  Table  III-l 
lists  all  the  error  codes  and  their  definitions. 


Table  III-l. 

Battalion  and  Group  Q-73  Error  Messages. 

Error 

Code 

Description 

Prog'&ms 

5020 

Invalid  message  id  for  message 
to  be  received  by  Q-73. 

T26Q 

5021 

Unable  to  find  Q-73  operator 

T159Q 

5022 

Unable  to  clear  Q-73  operator 

T159Q 

5023 

Unable  to  self-clear 

T159Q 

5200 

Increase  NEVEL 

GEV8A 

5201 

Incorrect  operator  type 

0EVALQ 

5202 

Data  Base  error 

INITQ 

5203 

Can't  find  covered  Track  in  Track  Data 

0EVALQ 

5204 

Increase  dimension  of  NFASS  array 

0TS15Q 

5205 

Incorrect  user  function  code 

USERFQ, 

USERNQ 

5206 

Incorrect  node  number 

UTBNQ 

W-142 
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IV.  MSA  I  NT  .'IETWORK  DATA 
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1-0  BH  Q-73  LISTING 

The  following  is  &  listing  of  the  MSAU7T  network  data  for 
the  Battalion  Q-73. 
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6£N,BATT  073,9,7,83,3* 

POP, 0,0, 13, 10, 10* 

US,  1,  CO,  0.0* 

BIS, 2, NO, .1,. 02,. 2, .07* 

BIS, 3, CO, 0.001* 

UTI,1 ,NUHINCQV* 

IHO, 1 , A* 

• 

*  BEAD  NODE  FO R  ROUTING  ENTITIES  TO  UHLN  THE  073  HAS  BEEN  DESTROYED 

*  BY  ENEMY  AIRCRAFT. 

* 

TAS,90,DEADNOD£,t,1,DS,1* 

UTC, 90, 0.0, 0.0, 1.0* 

H0D,90, t ,D,T* 

•  NO  BRANCH, ENTITY  IS  ELIMINATED  FROM  NETUORK 

•  SOURCE  TASKS 

• 

TAS.31 , CREATE TD, , ,DS, 1 , , ,S0* 

UTC, 31, 0.0, 0.0, 1.0* 

NOD, 31 ,1 »D,T* 

DEI, 31 ,30* 

* 

TAS,32,CREATTDA, , , DS, 1 , , ,S0* 

UTC, 32, 0.0, 0.0, 1.0* 

NOD, 32,1 ,D,T* 

DET,32,30* 

• 

•  OPERATOR  TASK  1,  SCAN  THE  SCREEN, DISPLAYS, ETC.  (TD/TDA) 

* 

TAS,1,IDLETINE,1,1,DS,1* 

UTC, 1,1.0, 3. 0,1.0* 

BET, 1,30* 

* 

*  OPERATOR  TASK  2,  CANCEL  SECONDARY  ASSIGNMENT  (TD) 

* 

TAS,2,CANC2ND,  1 ,1 ,DS,1* 

UTC, 2, 2. 0,1. 0,1.0* 

BET, 2, 3* 

*  . 

TAS,34,CANCL2,1,1,DS,1* 

UTC, 34,2. 0,2. 0,1.0, <12)1.0* 

BET, 30, 30* 

* 

*  OPERATOR  TASK  3,  SEND  TERMINATE  COMMANDS  (TD) 
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TAS,3,SENDTM,1,1,DS,1» 

UTC, 3, 3. 0,1. 0,1.0* 

SET, 3, 5* 

• 

TAS,37,6ENSPC,1,1,DS,1* 

UTC, 37, 3. 0,0. 0,1.0* 

CFI,3?,38,AEV,2.0,13,1A,,5,AEV,1.0,13,IA* 

• 

TAS,38,ENTSAD,1 ,1 ,DS,1* 

UTC, 38, 3. 0,0. 0,1.0* 

DET,38,39* 

• 

TAS,3?,SUICND,1,1,DS,1* 

UTC, 39, 3. 0,0. 0,1.0* 

CFI  ,39,4Q,AEV,1 .0,13,1A, ,41 ,AEV,2.0,13,IA* 

* 

TAS,40,SUIACT,1,1,DS,1* 

UTC, 40, 3. 0,0. 0,1.0* 

BET, 40, 42* 

• 

T  AS , 4 1 ,CHNCQDE,1 , 1 , DS ,  1  * 

UTC, 41, 3. 0,0. 0,1.0* 

BET, 41, 42* 

* 

TAS,42,ENDTSK3,1 ,1  ,DS,3* 

UTC, 42, 3. 0,2. 0,1. 0,(1211.0* 

NOD, 42,1 ,11, T* 

BET, 42, 30* 

• 

•  OFERATOR  TASK  4,  CLEAR  HOLD  FIRE, EFFECTIVE, STATUS  (TB) 

• 

TAS,4,ClRHES,1 , 1 , DS, 1  * 

UTC, 4, 4. 0,1. 0,1.0* 

BET, 4, 43* 

« 

TAS,43,BTHESDB,1 ,1 ,DS,1* 

UTC, 43, 4. 0, 0.0, 1.0* 

CFI,43,S,AEV,1.0,13,IA,, 

S,AEV,2.0,13,IA, , 

46,AEV,3.0,13,IA* 

* 

TAS,44,CLRHFE,1,1,DS,1* 

UTC, 44, 4. 0,0. 0,1.0* 

BET, 44, 46* 

• 

TAS,45,CLSSTS,1 ,1 ,DS,1* 


W 

/  ihli 

UTC, 45,4.0,0.0,1.0* 

BET, 45, 44* 

• 

4 

IAS,44,ENDTSK4,1 ,1 ,DS,3* 

UTC,44,4.0,2.0,1.0,(12)t.O* 

HOB, 44, 1 ,D,T* 

BET, 44, 30* 

E 

$ 

•  OPERATOR  TASK  5,  PERF0R.1  mQKIN6  PROCEDURE  (TD/TDA) 

•  . 

TASf5,PERFH00K,1 , 1 ,BS, 1  * 

BTC, 5, 5. 0,1. 0,1.0* 

CFI, 5,48, ALV,0.0, 9, IA,,4/,AG7, 0.0,9, IA* 

A 

E 

W 

TAS,47,P0SH00K, 1 ,1 ,BS,1* 

UTC, 47,5. 0,0. 0,1.0* 

BET, 47, 52* 

A 

is 

V 

TAS,52,PP0SHK,1 ,1 ,3S,1* 

UTC, 52, 5. 0,0. 0,1.0* 

BET, 52, 49* 

a 

frj 

{K\ 

¥ 

TAS,48,NUHHOOK,1,1,DS,1* 

UTC, 48, 5. 0,0. 0,1.0* 

& 

*-• 

BET, 48, 49* 

• 

IS 

TAS,49,H00KBRCH,1 ,1  ,DS,t* 

UTC, 49, 5. 0,0. 0,1.0* 

63 

HOB, 49,1 ,B,T* 

CFI,49,50,ALV,44.O,8,lA,, 

51 ,ALV,97.0,8,1A,, 

53, ALV, 1 42.0,8, 1 A* 

•in 

*  « 

* 

TAS ,50. HKRDUT 1 ,1,1, DS , 1  * 

v: 

UTC, 50, 5. 0,2.0, 1.0,112)1.0* 

HOB, 50, 1 ,B,T* 

CFI,50,34,AEV,34.0,8,IA, , 

37,AEV,37.0,8,1A,, 

E 

39,AEV,39.0,8,1A,, 

a* 

r- 

44, AEV,44.0,8,IA, , 

45, AEV,45.0,8,IA* 

* 

TAS, 51 ,HKR0UT2, 1 , 1 , BS , 1 • 

■  $ 

UTC,  51, 5. 0,2. 0,1. 0,112)1.0* 

HOD, 51 ,1 ,D,T* 

CFI,S1,70,AEV,70.0,8,IA,, 

.*** 

a£ 

V 

fc: 
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75,AEV,75.0,8,IA,, 

79,AEV,79.0,8,IA,, 

96, AEV, 96. 0,8, I A* 

* 

TAS,53,HKR0UT3,1,1,DS,1* 

UTC, 53,5.0,2.0,1.0,(12)1.0* 

«0D,33,1,D,T* 

CFI,53,  98, AEV,  98.0,8;1A,, 

108, AEV, 108. 0,8,1 A,, 

140, AEV, 140.0, 8, 1A* 

* 

•  OPERATOR  TASK  7,  ENTER  ID  DATA  (TDA) 

• 

TAS,7,CH1DFT,«,J,DS,1* 

UTC, 7, 7. 0,1. 0,1.0* 

CF1,7,63,AEV,1 .0, 13,IA, ,62, AEV, 2. 0,1 3, I A* 

* 

TAS,62,EHTC,1,1,DS,1* 

UTC, 62, 7. 0,0. 0,1.0* 

DET ,62,63* 

• 

TAS,63,ENTID,1 ,1 ,DS,1* 

UTC, 63, 7. 0,3. 0,1.0, (12)1.0* 

DET, 63, 30* 

*■ 

•  OPERATOR  TASK  8,  INTERROGATE  TARGET  (TDA) 

* 

TAS,8,INTTAR,1,1,DS,1* 

UTC, 8, 8. 0,1. 0,1.0* 

DET, 8, 66* 

• 

TAS,66,DETM,1,1,DS,t* 

UTC, 66, 8. 0,0. 0,1.0* 

CFI,66,67,AEV,1.0,13,1A,, 

5,AEV,2.0,13,IA,, 

71 ,AEV,3.0,13,IA* 

* 

T AS, 67, E NTMODE, 1 ,1 ,DS,1* 

UTC, 67, 8. 0,0. 0,1.0* 

DET, 47, 5* 

* 

TAS, 70, PRINTS, 1,1,DS,1* 

UTC, 70, 8. 0,0. 0,1.0* 

DET, 70, 72* 

* 

TAS, 71 ,PRH4CH,1 ,1 ,DS,1* 
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UTC, 71, 8. 0,0. 0,1.0* 

DET, 71 ,72* 

-  * 

TAS,72,ENDTSK8,1,1,DS,3* 

OTC, 72, 8. 0,2. 0,1.0, (12)1.0* 

H0D,72, 1 ,D,T* 

DET, 72, 30* 

• 

*  OPERATOR  TASK  10,  SEND  COMMAND  MESSAGE  CTD) 

* 

TAS,1C,SNDCQMM,1,1,PS,U 
UTC, 10, 10. 0,1. 0,1.0* 

DET, 10, 5* 

* 

TAS,75,DETGENS?,1,1,DS,1* 

UTC, 75, 10. 0,1. 0,1.0* 

CFI,75,S,AEV,1 .0,1 3,1 A,, 

74,AEV,2.0,13,IA,, 

79, AEV, 3. 0,13,1a* 

* 

TAS,74,ENTSFUA,1,1,DS,1* 

UTC, 74, 10. 0,0. 0,1.0* 

DET, 74, 79* 

* 

TAS,79,ENTCCC,1,1 , DS,1* 

UTC, 79, 10. 0,2. 0,1. 0, <12)1.0* 

DET, 79, 30* 

• 

*  OPERATOR  TASK  IS,  ASSIGN  UEAPONS 

t 

TAS,15, ASSUEAPN, 1 ,1 ,DS,1* 

UTC, 15, 15. 0,1. 0,1.0* 

CFI  ,15,5, AEV, 1 .0, 13, 1 A, ,95, AEV ,2. 0,1 3, 1 A* 

• 

TAS,95,PRAARECM,1 ,1  ,DS,1* 

UTC, 95, 15. 0,0. 0,1.0* 

DET, 95, 102* 

* 

T AS ,94, KOOK ADR, t , 1 ,DS,1* 

UTC, 94, 15. 0,0. 0,1.0* 

CFI ,94, 5, AEV, 1 .0,1 3, I A,, 97, AEV, 2. 0,1 3, I A* 

* 

TAS,97,ENTADRSS,1 , 1 , DS ,  1  * 

UTC, 97, 15. 0,0. 0,1.0* 

DET, 97, 98* 

• 
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TAS,98,SU0RCCEN,1,1,DS,1* 

UTC, 98, 15. 0,0. 0,1.0* 

Cf 1,98,1 00, A£V, 1 .0,13, IA, ,99,AEV,2.0,13,iA* 

* 

VAS,99,PRSADLDT,1 ,1 ,DS,1* 

UTC, 99, 15. 0,0. 0,1.0* 

Lt£T,99,102* 

* 

TAS,100,PRSASSN,1,1,DS,1* 

UTC, 100, 15. 0,0. 0,1.0* 

DET, 1 00,101* 

* 

T  AS , 101 ,PRSAPPR,1 ,1  ,DS,1* 

UTC, 101, 15. 0,0. 0,1.0* 

BET, 101, 102* 

* 

TAS, 102,ENDTSK15, 1 , 1  ,BS,3* 

UTC, 102, 15. 0,2. 0,1.0, (12)1.0* 

HOD, 102,1 ,D,T* 

BET, 102, 30* 

* 

*  OPERATOR  TASK  20,  RECEIVE  COMMANDS  <TD) 

• 

TAS,20,RECCHB,1 ,1  ,DS,1* 

UTC, 20, 20. 0,1. 0,1.0* 

BET, 20, 5* 

• 

TAS,108fEXMALERT,1 ,1 ,BS,1* 

UTC, 108, 20. 0,0. 0,1.0* 

CFI,108,109,AEV,1.0,13,IA,,110,AEV,2.0,13,IA* 

* 

TAS,10?,PR5CLRA,t,1,DS,1* 

UTC, 109, 20. 0,0. 0,1.0* 

BET, 109, 111* 

* 

TAS,1 10,ENTCOHCD,1 ,1 ,DS,1* 

UTC, 110, 20. 0,0. 0,1.0* 

BET, 110, 111* 

* 

TAS,1 1 1 ,ENDTSK20,1 ,1 ,DS,3* 

UTC, 111, 20. 0,2. 0,1.0, <12)1.0* 

H0D,1 11,1 ,D,T* 

BET, 111, 30* 

* 

•  OPERATOR  TASK  22,  CLEAR  ALERTS 

* 


W-H9 


TAS,22,DETAl£RT,1,1,D$,1* 

UTC, 22, 22.0,t. 0,1.0* 

CFI,22,143,AEV,t .0,13,IA,,140,AGV,16.0,13,IA* 

* 

IAS,  H3,A;.ERT1 ,1 ,1  ,DS,1* 

UTC, 143, 22. 0,0. 0,1.0* 

D£T,143,144* 

* 

TAS,140,UHFUALRT,1,1,DS,1* 

UTC, 140, 22. 0,0. 0,1.0* 

CH,140,142,AEV,16.0,13,IA,, 

145, AEV,20.0,13,IA,, 

146, A£V,93.0,13,IA* 

• 

TAS, 1 42, ALERT  1 6, 1 ,  1 ,DS,1* 

UTC, 142, 22. 0,0. 0,1.0* 

BET, 142, 144* 

♦ 

TAS,145,ALERT20,1 ,1  ,DS,1* 

UTC, 145, 22. 0,0. 0,1.0* 

DET  ,145,1 44* 

• 

TAS,146,ALERT93,1 ,1,OS,1* 

UTC, 146, 22. 0,0. 0,1.0* 

BET, 146, 144* 

* 

fAS,144,ENDTSK22,1 ,1 ,ES,3* 

UTC, 144, 22. 0,2. 0,1.0, (12)1.0* 

HOD, 144,1 ,B,T* 

DET, 144, 30* 

* 

*  OPERATOR  TASK  26  TO  RECEIVE  HISCEtlANEOUS  HESSAGES 

* 

TAS,26,DETHSGN,1 ,1 ,BS,1* 

UTC, 26, 26. 0,1  . 0,1  .0* 

HOD, 26, 1 ,D,T* 

DET, 26, 159* 

* 

TAS, 159, RECHSG 17,1 ,1 ,DS, 1  * 

UTC, 159, 26. 0,0. 0,1  .0* 

HOD, 159,1 ,D,T* 

DET, 159,30* 

• 

*  OPERATOR  TASK  30,  TASK  SEQUENCING 

* 

TAS.30, TASKSEQ,! ,t ,DS,t* 


UTC, 30, 30. 0,1  . 0,1.0* 

H0Df3>\1fM* 

CrI ,30, 191 , AEV, 1 . 0 ,3, IA, , 192, AEV ,2. 0,3, I A* 

* 

TAS,191,TSEQTD,1,1,DS,1* 
ore, 191,30. 0,0. 0,1.0* 

HOD, 191 , 1 ,D,T* 

CF 1 , 1  y  1 ,  193, ALV, 6. 0,1 4,1 A,, 194, AGV, 5. 0,1 4, 1 A* 

* 

TA3, 1 y3, TDR0UTE1 , t , 1 ,DS, 1  * 

UTC, 193, 30. 0,2. 0,1.0, <12)1.0* 

HOD, 193,1 ,D,T* 

CFI, 193,1, AEV, 1.0,14,1a,, 

2,  AEV, 2.0,14,IA,, 

3,  AEV, 3.0, 14, IA,, 

4,  AEV, 4.0, 14, IA,, 

5,  AEV, 5.0, 14, IA* 

• 

TAS, 194,TDR0UTE2, 1 ,1 ,DS,1* 

UTC, 194, 30. 0,2. 0,1.0, <12)1.0* 

HOD, 194,1 ,D,T* 

CFI, 194, 10, AEV, 10.0, 14, IA,, 

IS, AEV, 15.0, 14, IA,, 

20, AEV, 20.0, 14, IA,, 

22, AEV, 22.0, 14, IA,, 

24,AEV,26.0,14,1A* 

* 

TAS, 192 .TSEQTDA, 1 , 1 ,DS,  1  * 

UTC, 192, 30. 0,0. 0,1.0* 

HOD, 192,1 ,D,T* 

CFI , 192, 1 95, ALV,8 .0,1 4,1A, ,196, AGV, 7.0, 14,1  A* 
* 

TAS, 1 95 , TDAROUT t , 1 , 1 ,DS, 1  * 

UTC, 195, 30. 0,2. 0,1.0, <12)1.0* 

HOD, 1 95,1 ,D,T* 

CFI, 195,1, AEV, 1.0, 14, IA,, 

5, AEV, 5.0, 14, IA,, 

7, AEV, 7.0, 14, IA* 

* 

TAS , 1 96 , TDAROUT 2, 1 , 1 ,DS ,  1* 

UTC, 196, 30. 0,2. 0,1.0, <12)1.0* 

HOC, 1 96 , 1 , D , T  * 

CFI, 196,  8, AEV,  8.0, 1 4 , IA, , 

22, AEV, 22.0, 14, IA,, 

26, AEV, 26.0, 14, IA* 
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2-G  GROUP  Q-73  LISTING 

The  following  is  a  listing  of  the  MSAINT  network  data  for 
the  Group  Q-73. 
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GEN, GROUP  073,9,7,83,3* 

POP, 0,0,11, 10, 10* 

DIS, 1,00,0.0* 

DiS,2,N0,.1,.02,.2,.07* 

PIS, 3, CO, 0.001* 

IHU,1,A* 

• 

*  DEAD  NODE  FOR  ROUTING  ENTITIES  TO  UHEN  THE  Q73  HAS  BEEN  DESTROYED 

*  BY  ENEMY  AIRCRAFT. 

* 

TAS  ,90,  DE.TDMQDE ,  1 , 1 ,  DS ,  1  * 

UTC, 90, 0.0,0. 0,1.0* 

HOD, 90, 1 , D,T* 

*  NO  BRANCH, ENTITY  IS  EUHINATED  FROM  NETWORK 

* 

*  SOURCE  TASKS 

* 

TAS,31 , CREATE  TD , , ,DS, 1 , , ,S0* 

UTC, 31, 0.0, 0.0, 1.0* 

HOD, 31 , 1 ,D,T* 

DET,31 ,30* 

* 

TAS,32,CREATTD2, ,,DS,1,,,S0* 

UTC, 32,0, 0,0.0, 1 .0* 

HOD, 32,1 ,D,T* 

DET ,32,30* 

* 

*  OPERATOR  TASK  1,SCAN  THE  SCREEN, DISPLAYS, ETC. 

* 

UTC, 1.1. 0,3, 0,1.0* 

DET, 1,30* 

* 

*  OPERATOR  TASK  3,  SEND  TERHINATE  COMMANDS  (TD) 

• 

TAS,3,SENDTH,1,1,DS,1* 

UTC, 3, 3. 0,1. 0,1.0* 

DET, 3, 5* 

* 

TAS,37,GENSPC,1,1,DS,1* 

UTC, 37, 3. 0,0. 0,1.0* 

CFI,37,38,AEV,2.0,)3,1A, ,5, AEV ,1.0, 13,1 A* 

• 

TAS,38,ENTSAD,1,1,DS,1* 

UTC, 38, 3. 0,0. 0,1.0* 

DET, 38, 39* 
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TAS,2?,SUir.M0,1,1,DS,1* 

UTCr39,3.0,0.0,1.0* 

CFI ,39,40 , AEV,  1 .0,13,IA,,41 ,AEV,2.0,1 3, IA* 

* 

TAS,40,SUIACT,1 , 1 ,DS,1* 

UTC, 40, 3. 0,0. 0,1.0* 

DET, 40,42* 

* 

TAS, 41 ,CHNCODE, 1 , 1 ,DS,1* 

UTC, 41, 3. 0,0. 0,1.0* 

DET, 41, 42* 

* 

TAS,42,ENDT3K3,1 ,1 ,DS,3* 

UTC, 42, 3. 0,2. 0,1.0, (12)1.0* 

HOD, 42,1 , D , T  * 

DET, 42,30* 

* 

*  OPERATOR  TASK  5,  PERFORM  HOOKING  PROCEDURE 

* 

TAS,5,PERFH00K, 1 , 1 ,DS, 1  * 

UTC, 5, 5. 0,1. 0,1.0* 

CFI, 5, 48, ALV, 0.0,9.14, , 47, AG V, 0.0, 9, 1  A* 

* 

TAS,47,P0SH00K,1,1,DS,1* 

UTC, 47, 5. 0,0. 0,1.0* 

DET, 47, 52* 

* 

TAS,52,PP0SHK,1 , 1 ,DS,1* 

UTC, 52, 5. 0,0. 0,1.0* 

DET, 52, 53* 

* 

TAS,48,NUHHO0k,1 , 1,DS,1* 

UTC, 48, 5. 0,0. 0,1.0* 

DET, 48, 53* 

* 

TAS,53,H00KBRCH,1 ,1 ,DS,1* 

UTC, 53, 5. 0,2. 0,1.0, (17)1.0* 

HOD, 53,1 ,D,T* 

CFI, 49, 37, AEV, 37. 0,8, I A,, 

39,AEV,39,0,8,IA* 

* 

*  OPERATOR  TAJK  26  7D  RECEIVE  MISCELLANEOUS  MESSAGES 

* 

TAS,26,DETHSGN,1,t,DS,1* 

UTC, 26, 26. 0,1. 0,1.0* 

MOD, 26,1 ,D,T* 
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it I, 26, 159, 1EV. 17. 0, 13, IA,, 160, AEV, 11.0,13,1ft* 

TAS,159,RECHSG17,1,1,D3,i* 

UK, 159,26, 0,0. 0,1.0* 

MOD,159,1,0,T* 

DET, 159,161* 

* 

TAb,160,RCCHSG1 1,1,1, DS , i • 

OK,  160, 26. 0,0. 0,1.0* 

HOD, 160,1 ,D,T* 

SET, 160, 161* 

* 

TAS, 161 .ENDTS26, 1 ,1 ,DS,1* 

UTC, 161, 26. 0,2. 0,1.0* 

MOD, 161 ,1,D,T* 

DET,  161, 30* 

•  | 

•  DrERATOR  TASK  30,  TASK  SEQUENCING 


a  fci 
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TAS,30,TASKSEQ,1 , 1 ,DS,1* 
UTC,  30, 30. 0,1. 0,1.0* 

MOD, 30,1 ,D,T» 

DET, 30, 191* 


TAS,  191 , TSEQTD, 1 , 1 ,DS , 1* 

UTC, 191, 30. 0,0. 0,1.0* 

HOD, 191 ,1 ,D,T* 

CFI,191,193,AIV,6.0,14,IA,,194,A6V,5.0,14,IA* 

• 

TAS,193,TDR0UTE1,1,1,DS,1» 

UTC, 193, 30. 0,2. 0,1  .0, <12)5.0* 

MOD, 193,1 ,D,T* 

CFI, 193,1, AEV, 1.0, 14, IA,, 

3, AEV, 3.0, 14, 1A,, 

5, AEV, 5.0, 14, IA* 

* 

TAS,194,TDR0UTE2,1,1.DS,1* 

UTC, 194, 30. 0,2. 0,1  .0, <12)1.0* 

MOD, 194,1 ,D,T« 

DET, 194,26* 

t 
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MOPADS  Terminology 


AIR  DEFENSE  SYSTEM 

A  component  of  AJLr  Defense  vhich  includes 
equipment  and  operators  and  for  vhich 
technical  and  tactical  training  are  required. 
Examples  are  1HAWK  and  the  AH/TSQ-73- 

AIR  DEFENSE  SYSTEM 
MODULE  (ADSM) 

Models  of  operator  actions  and  equipment 
characteristics  for  Air  Defense  Systems  in 
the  MOPADS  software.  These  models  are  pre¬ 
pared  with  the  SAINT  simulation  language. 

Air  Defense  System  Modules  include  the 

SAINT  model  and  all  data  needed  to  com¬ 
pletely  define  task  element  times,  task 
sequencing  requirements,  and  human  factors 
influences. 

AIR  SCENARIO 

A  spatial  and  temporal  record  of  ac:  ial 
activities  and  characteristics  of  an  air 
defense  battle.  The  Air  Scenario  inc'md's 
aircraft  tracks,  safe  corridors,  PCM,  and 
other  aircraft  and  airspace  data,  lee 
also  Tactical  Scenario. 

BRANCHING 

A  term  vued  in  the  SAINT  simulation  lang¬ 
uage  to  mean  the  process  by  which  TASK  nodes 
are  sequenced.  At  the  completion  of  the 
simulated  activity  at  a  TASK  node,  the 
Branching  from  that  node  determines  vhich 
TASK  nodes  will  be  simulated  next. 

DATA  BASE  CONTROL 
SYSTEM 

That  part  of  the  MOPADS  software  .'hi.** 
performs  all  direct  communication  with  the 
MOF.iDS  Data  Base.  All  infcmcitiOa  transfer 
to  and  from  the  data  base  is  performed  by 
invoking  the  subprogram*  which  make  up  the 
Data  Base  Control  System 

DATA  SOURCE 

SPECIALIST 

A  specialist  in  obtaining  and  interpreting 
Army  documentation  and  other  data  needed  to 
prepare  Air  Defense  System  Modules. 

ENVIRONMENTAL 
STATE  VARIABLE 


Aa  element  of  en  Environmental  State 
Vector. 


i 
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V* 
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ENVIRONMENTAL 
STATE  VECTOR 


An  array  of  values  representing  conditions 
or  characteristics  that,  may  affect  more 
than  one  operator.  Elements  of  Environmen¬ 
tal  State  Vectors  may  change  dynamically 
curing  a  MOPADS  simulation  to  represent 
changes  in  the  environment  conditions. 


MODERATOR  FUNCTION 


A  aathematical/logical  relationship  vhich 
alters  the  nominal  tine  to  perform  an  opera¬ 
tor  activity  (usually  a  lash  Element).  The 
nominal  tine  is  changed  to  represent  the 
operator's  capability  to  perform  the 
activity  based  on  the  Operator's  Stat 
Vector. 


MCPADS  DATA  BASE  A  computerised  data  base  designed  specifi¬ 

cally  to  support  the  MOP;  3  software.  The 
MOPADS  Data  Base  contains  Simulation  Data 
Set(s).  It  communicates  interactively  with 
MOPADS  Users  during  pre-  and  post-run  data 
specification  and  dynamically  with  the  SAINT 
software  during  simulation. 


MOPADS  MODELER 


An  analyst  who  will  develop  Air  Defense 
System  Modules  end  modify/ develop  the  $ 
MOPADS  software  system. 


MOPADS  USER  An  analyst  who  will  design  and  conduct  simu¬ 

lation  experiments  with  the  MOPADS  software. 


MSA  I  NT  The  variant  of  SAINT  used  in  the  MOPADS 

{ MOPADS/SAINT)  system.  The  standard  version  of  SAINT  has 

been  modified  for  MOPADS  to  permit  share¬ 
able  subnetworks  and  more  sophisticated 
interrupts.  Tne  terms  SAINT  and  MSATNT  are 
used  interchangeably  when  no  confusion  will 
result.  See  also,  SAINT. 
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OPERrtTOR  state 
VARIABLE 


V 


OPERATOR  STATE 
VECTOR 

OPERATOR  TASK 

SAINT 

SIMULATION  DATA  SET 

SIMULATION  STATE 

SYSTEM  MODULES 
TACTICAL  SCENARIO 


One  element  of  cm  Onerator  State  Vector. 


An  erray  of  values  representing  the  condi¬ 
tion  and  characteristics  of  an  operator  of 
an  Air  Defense  System.  Many  values  of  the 
Operator  State  Vector  vill  change  dynamically 
during  the  course  of  a  MOPADS  simulation  to 
reprscent  changes  in  operator  condition. 


An  operator  activity  identified  during 
veapons  system  front-end  analyses. 


The  underlying  computer  simulation  language 
used  to  model  Air  1)e  ;  <;  Systems  in  Air 

Defense  System  Modules.  SAH3T  is  an  acronym 
for  Systems  Analysis  of  Integrated  Networks 
of  Tasfcs.  It  is  a  veil  documented  language 
designed  specifically  to  represent  human 
factors  aspects  of  man /machine  systems. 

See  also  MSAIUT. 


The  Tactical  Scenario  plus  all  required 
simulation  initialisation  and  other  experi¬ 
mental  data  needed  to  perform  a  MOPADS 
simulation. 


At  any  instant 


time  of  a  MOPADS  simula¬ 


tion  the  Simulation  State  is  the  set  of 
values  of  *1 1  variables  in  the  MOPADS  soft¬ 
ware  and  the  MOPADS  Data  Base. 


See  Air  Defense  System  Modules. 


The  Air  Scenario  plus  specification  of 
critical  assets  and  the  air  defense  con¬ 
figuration  (number,  type  and  location  of 
veapons  and  the  command  and  control  system) . 
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TACTICAL  SCENARIO 
COMPONENT 

As  element  of  a  Tactical  Scenario,  e.g., 
if  a  Tactical  Scenario  contains  several 
A-73's,  each  one  is  a  Tactical  Scenario 
Coupon est. 

TASK 

See  Operator  Task. 

TASK  ELEMENTS 

Individual  operator  actions  vhich,  vhsn 
grouped  appropriately,  rakr  up  operator 
tasks.  Task  elements  are  usually  repre¬ 
sented  by  single  SAINT  TASK  nodes  in  Air 
Defense  System  Modules. 

TASK  NODE 

A  modeling  symbol  used  It  the  SAINT  simula¬ 
tion  language.  A  TASK  node  represents  an 
activity;  depending  upon  the  modeling  cir¬ 
cumstances,  a  TASK  node  may  represent  an 
individual  activity  such  as  a  Task  Element, 
or  it  may  represent  en  aggregated  activity 
such  as  an  entire  Operator  Task. 

TASK  SEQUENCING 
MODERATOR 

FUNCTION 

A  mathematical/logical  relationship  vhich 
selects  the  next  Operator  Task  vhich  an 
operator  vill  perform.  The  selection  is 
based  upon  operator  goal  seeking  character¬ 
istics. 

Additional  Terair.cloQr 


ADP 

Automatic  Date  Processor 

ASO 

Azimuth  Speed  Operator 

ATDL 

Automatic  Tactical  Data  Link 

BCC 

Battery  Control  Central 

ECM 

Electronic  Countermeasure 

FCO 

Firing  Console  Operator 

PCP 

Platoon  Command  Post 

X-8 
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TCA 


Tactical  Control  Assiscant 


TCC 


Tactical  Control  Console 


TCO 


Tactical  Control  Officer 
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I.  OVERVIEW  OF  THE  HOPAIS  HOTEL 


e 


This  report  documents  the  implementation  details  of  the  IHAWK 
system  module.  It’s  Intended  audience  is  the  MOPADS  modeler  vho 
must  maintain  and  explain  the  model.  A  companion  report  ( loodin  & 
Folito  (1983))  provides  user  information  for  the  MOPADS  user. 

The  MOPADS  operator  tasks  are  modeled  viuh  subnetworks  of 
MSA1NT  task  nodes.  Each  node  has  a  subroutine  of  user  code  assoc¬ 
iated  with  it  where  the  user  may  write  code  to  access  the  data  • 
base  and  modify  the  MSAIKT  data  structure.  These  task  node  sub¬ 
routines  are  named  according  to  the  task  node  they  represent. 

For  instance,  the  subroutine  used  to  process  logic  associated  with 
node  175  is  named  T175W  and  the  one  for  node  6 2  is  named  T62W. 

| 

The  five  operators  perform  various  task  nodes  in  the  network. 
The  two  Firing  Console  Open  tors  (FCOs)  are  the  only  operauors  who 
may  perform  the  same  task  ncfdles;  other  operators  perform  a  unique 
set  of  tasks.  The  operators  communicate  with  one  another  by 
sending  messages,  signaling  (clearing  one  operator  to  another  node ) , 
altering  the  data  base,  or  altering  the  KSAIUT  data  structure. 

Table  1-1  is  a  list  of  some  of  the  assumptions  made: in  con¬ 
structing  the  MOPAES  model  of  the  IHAWK. 
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Table  1-1.  Assumptions. 


1)  Jamming  and  ECM  are  nnt  considered 

2)  All  setup,  checkout  and  emplacement  procedures  have  been 
performed. . 

3)  The  IHAWK  will  not  be  mobile  during  the  simulation. 

4)  The  automatic  firing  mode  w*ll  not  be  employed. 

5)  All  ADP's  remain  operational  assuming  the  IHAWK  has  not 
been  destroyed. 

6)  The  use  of  the  IHAWK  in  the  PCP  (Platoon  Command  Post)  is 
not  represented. 

7)  The  ATDL  data  link  is  used  for  communicating  with 
Battalion  AN/TSQ-73. 

8)  The  TCO  receives  all  messages  from  Battalion. 

9)  No  communication  occurs  between  IHAWK  units  except  for 
those  passed  up  through  the  Battalion. 

10)  The  IHIPIR  radars  will  always  acquire  lock. 

11)  A  target  will  be  positively  identified  if  the  TCA  performs 
IFF  procedures  on  that  target. 

12)  All  targets  fired  upon  will  be  destroyed  unless  the 
CHANGE  TARGETS  task  is  performed  by  the  FCO. 

13)  The  TCO  must  ask  permission  to  fire  from  Battalion  before 
engaging  a  target  other  than  a  self-initiated  engagement. 

14)  The  FCO  must  manually  select  launchers. 

15)  The  CEASE  FIRE  command  will  not  be  modeled. 

16)  TCO  will  make  all  weapon  assignments. 


II.  MODEL  DESCRIPTION  FORMS 


1-0  ebtitits 

The  operators  that  perform  the  work  in  the  Battery  Control 
Center  (BCC)  are  the  entities  in  the  IHAWK  system  module.  The 
forms  in  this  section  describe  each  entity,  their  attributes,  and 
their  resource  requirements. 
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WHERE  DESCRIPTION  AilRlBUlT]  DEFTSITIoH  INI UAL  VALUE  RESOURCE 

CREATED  NUHBER  UF  APPROPRIATE)  REQUIREMENTS 
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2-0  RESOURCES 


The  launchers  are  modeled  as  resources  in  the  IHAWK  system 
module.  There  are  six  launchers  for  each  IHAWK  (three  for  each 
fire  section).  The  following  forms  describe  each  of  the 
resources  and  their  attributes  used  during  the  simulation. 


system  attributes,  and  user  variables  used  in  the  IHAWK  system 
module.  Table  II-l,  shown  after  the  forms,  expands  the  defini¬ 
tion  for  the  variable  TSVALW. 
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StHH  f  VARIABLES  _ P*S»A _«»f  . 


^  % 


U-0  TASK  NETWORKS 


►*V  In  this  section  ax-e  the  forms  used  to  document  each  of  the 

operator  tasks  and  each  individual  node  in  those  tasks.  Each 
operator  task  is  documented  by  two  types  of  forms:  MSAINT  TASK 
MODELS  and  MSAINT  TASK  NETWORKS.  The  MSAINT  TASK  MODEL  forms 
give  a  written  description  of  the  activities  involved  of  each 
node  on  the  network.  The  MSAINT  TASK  NETWORKS  forms  contain  the 
MSAINT  subnetworks  used  to  describe  each  operator  task.  Following 
these  two  forms  for  each  task  is  the  TASK  NODE  SPECIFIC  DATA  forms 
for  each  node  in  the  operator  task  (MSAINT  subnetwork).  These 
forms  contain  the  information  stored  in  the  data  base  for  each 
node . 

Note  that  the  source  nodes,  the  dead  rode,  and  the  task 
sequencing  subnetwork  are  also  contained  in  this  section.  These 
particular  nodes  are  not  shown  on  the  MSAINT  TASK  MODEL  forms 
because  there  are  no  operator  actions  involved. 

Table  II-2,  at  the  end  of  this  section,  is  a  cross-reference 
table  that  may  be  used  to  look  up  which  operator  tasks  are 
associated  with  -which  nodes. 
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IASK  NODE  SPECIFIC  PAIA _ of.l. 


Table  II-2 


CROSS  REFERENCE  OF  NODE  NUMBERS  TO  OPERATOR  TASK  NUMBERS 

FOR 

IHAWK  SYSTEM  MODULE 


MSAINT 

NODE 

NUMBER 

TASK 

LABEL 

OPERATOR 

TASK 

NUMBER 

MSAINT 

NODE 

NUMBER 

TASK 

LABEL 

OPERATOR 

TASK 

NUMBER 

1 

ASOSTNB 

1 

41 

2 

DTCTCWAR 

2 

42 

3 

ESTTARPR 

3 

43 

4 

REQCLRAl 

4 

44 

5 

POSCWCRS 

5 

45 

SOURCTCO 

- 

5 

OBSVALEX 

6 

46 

SOURCTCA 

• 

7 

FCOSTNDB 

7 

47 

SOURCASO 

• 

8 

DROCADP 

8 

48 

SOURCFCA 

• 

9 

POSCURS 

9 

49 

SOURCFCB 

• 

10 

PSHFSOFF 

10 

50 

11 

MONTDOPA 

11 

51 

12 

OBSVLNCH 

12 

c2 

13 

DECFCTYP 

13 

53 

14 

WAITINTP 

14 

54 

15 

PSHFSACT 

15 

55 

16 

PRCHTRGT 

16 

56 

17 

TCASTNBD 

17 

57 

18 

PCCHANDW 

18 

58 

19 

SLTIFFM 

19 

59 

20 

DCDATDLS 

20 

60 

PRHLDCT 

26 

21 

TC0STND8 

21 

61 

ENDTSK26 

26 

22 

DTCTIPAR 

22 

62 

DCDFIRET 

27 

23 

EVALTHRT 

23 

63 

ISSF1RFC 

27 

24 

EVALHDAT 

24 

64 

ENDTSK27 

27 

25 

SNDCCOMP 

25 

65 

26 

HIGHPRI 

26 

66 

27 

SETRFCFR 

27 

67 

28 

PP.SSCHT 

28 

68 

29 

OCAADCPF 

29 

69 

PLTRCKSY 

29 

30 

TOGRCCF 

30 

70 

PRSSFSW 

29 

31 

PERMCNCL 

31 

71 

STRFSW 

29 

32 

TCORMSG 

32 

72 

ENDTSK29 

29 

33 

73 

BYDEFFR 

34 

34 

74 

ONOKILL 

30 

35 

RCVHLDFR 

35 

75 

ENDTSK30 

30 

36 

76 

37 

OBCSENPGD 

37 

77 

RECQ73M  ■ 

32 

38 

78 

RECFCOM 

32 

39 

79 

RECASOM 

32 

40 

TASKSEQW 

40 

80 

ENDTSK32 

32 
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Table  II-2  (continued) 


CROSS  REFERENCE  OF  NODE  NUMBERS  TO  OPERATOR  TASK  NUMBERS 

FOR 

IHAWT  SYSTEM  MODULE 


MSAINT 

NODE 

mJMEER 

TASK 

LABEL 

OPERATOR 

TASK 

NUMBER 

MSAINT 

NODE 

NUMBER 

TASK 

LABEL 

OPERATOR 

TASK 

NUMBER 

81 

RECTCAM 

32 

121 

PRSFLSHE 

9 

82 

122 

DCDHIPLK 

9 

83 

123 

TARGALT 

9 

84 

124 

ENDTSK09 

9 

85 

125 

86 

126 

87 

127 

88 

ENDTSK10 

10 

128 

89 

WAITRELD 

10 

129 

90 

DEADNODl: 

- 

130 

91 

TCOTSEQ 

40 

131 

92 

ASOTSEQ 

40 

132 

93 

TCATSEQ 

40 

133 

DCDRDSIZ 

11 

94 

FCOTSEQ 

40 

134 

PSHOFM 

11 

95 

T COROUT 1 

40 

135 

96 

TCCR0UT2 

40 

136 

LCHRDLAY 

13 

97 

TC0R0UT3 

40 

137 

ENDTSK11 

11 

98 

138 

ENDTS12 

12 

99 

FCOROinn 

40 

139 

PSHFBRP 

13 

100 

FC0R0UT2 

40 

140 

WAITRPFR 

13 

101 

WAITMSGK 

14 

141 

102 

142 

ENDTSK13 

13 

103 

143 

PSHFBSLS 

13 

104 

144 

-AUDTNBST 

14 

105 

145 

DROPDOP 

14 

106 

LOWPRCOF 

3 

146 

GVERBNK 

14 

107 

WAITTCOfo 

4 

147 

PSHNOKLL 

14 

108 

PRSALCNL 

4 

148 

PRSKILLB 

14 

109 

PSWSLFW 

5 

149 

PRSBRKLK 

14 

110 

PRSTCCAB 

5 

150 

SHOOTEM 

14 

111 

MRKTARGT 

6 

151 

112 

OBSRCHLM 

8 

152 

PACKNWL 

37 

113 

DHIPIRLK 

8 

153 

DCDMSSEN 

37 

114 

154 

OFCOBLCK 

37 

115 

OBVLOCKL 

8 

155 

ENDTSK37 

37 

116 

156 

117 

ENDTSK08 

8 

157 

PRACKNOW 

35 

118 

158 

PRSDESTR 

35 

119 

159 

OFCOBLK 

35 

120 

OBASSLTP 

8 

160 

ENDTSK14 

14 
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Table  II-2  (continued) 


CROSS  REFERENCE  OF  NODE  NUMBERS  TO  OPERATOR  TASK  NUMBERS 

FOR 

IHAWK  SYSTEM  MODULE 


MSAINT 

NODE 

NUMBER 

TASK 

LABEL 

OPERATOR 

TASK 

NUMBER 

161 

PSHBREAK 

16 

162 

PRCWC0NF 

18 

163 

CORLTGT 

18 

164 

WAITSWEP 

19 

165 

MONIFFN 

19 

166 

MRKRFLCT 

20 

167 

ENDTSK20 

20 

168 

IFFBATT 

22 

169 

PRFLASH 

22 

170 

ENDTSK22 

22 

171 

172 

173 

174 

175 

176 

177 

178 

0IFFM0N 

23 

179 

DECATDLD 

23 

180 

DETLOC 

23 

181 

PTSOVPPI 

23 

182 

PALAB 

23 

183 

184 

185 

186 

- 

187 

ENDTSK23 

23 

188 

PLTSOVAS 

23 

189 

PRENOTH 

23 

190 

OBVLBLS 

23 

191 

192 

193 

194 

FCOESTS 

24 

195 

OIFFTC 

24 

195 

197 

198 

199 

200 

MSAINT 

NODE 

NUMBER 

TASK 

LABEL 

OPERATOR 

TASK 

NUMBER 

5-0  USER  FUNCTIONS 

This  section  contains  the  forms  used  to  describe  the  user, 
functions  called  in  the  simulation. 


6- 0  MODERATOR  FUNCTIOH 

There  is  only  one  moderator  function  (referred  to  as 
Moderator  Function  #1)  used  by  the  IHAVK.  This  moderator  func¬ 
tion  allows  the  user  to  gain  access  to  the  human  factors  codes 
for  moderating  task  performance  time. 

Any  task  node  that  has  moderator  function  one  active  must 
have  skills  and  distribution  data  stored  in  the  data  base,  and 
the  task  time  on  the  Task  data  card  must  be  specified  as  DS,1. 

7- 0  MESSAGES  SENT  FROM  IHAWK  SYSTEM  MODULE 

The  following  forms  describe  each  of  the  messages  sent  from 
operators  in  the  IHAWK  system  module  to  operators  within  the 
IHAWK  and  to  operators  in  Battalion  AN/TSQ-T3. 


HOPABS  MESSAGE  DESCRIPTION 


Message  No.  14 

MESSAGE  IB  ELEMENT 

Page  1  of  1 

1 

2 

3 

4 

5 

« 

lescriptioB 

Receiver  CRN 

Operator  Type 

Functional  Type 

Message  Subtype 

Message  Priority 

Value 

1 

k 

h 

z 

MESSAGE  BATA  LINK  ELEMENT 

Elewe.nl 

Besr  notion 

Value 

1 

Connumcation  Network 

1-Voice  2-ATDL  , 

2 

2 

Acknoeledgenent  Required 

,  1  -  Yes  2  -  No  1 

2 

3 

Unused 

4 

ATDL  Code  (Unused)  | 

— 

5 

* 

Tine  Message  Sent 

— 

6 

• 

Message  Nunber 

— 

7 

♦ 

Sender  CRN 

— 

8 

Sender  Operator  Type 

3 

9 

Sender  Systen  Module  Type 

4 

10 

Task  Node  Nunber  Sent  Fron 

" 

*  Must  be  set  at  the  tine  the  nessage  is  sent 


1 

2 


VARIABLE  MESSAGE  FORMAT 

- 1 - 

Description 

WORDS  =  1 

Message  Number  Acknowledging 


MESSAGE  SUBTYPE  DESCRIPTION 
Acknowledge  Message  -  "Will  Comply" 


Nane: 

Bate: 


Riley  Goodin 
12/20/83 

T'" 


ISysten  Module: 

Project: 
- T . 


IHAWK 

MOPADS 


Fron 

IHaWK( 35 ) 


_ To 

BN( 22 ) 


Fro* 


To 


i 


HOP AOS  MESSAGE  DESCRIPTION 


hftitst  Ho.  15  NESSASE  IS  ELEMENT  T»jl  2  of  2 


Element 

Description 

Value 

1 

•  Receiver  CRN 

— 

2 

Operator  Type 

1 

3 

Functional  Type 

k 

4 

Message  Subtype 

5 

S 

Message  Priority 

k 

MESSAGE  DATA  LINK  ELEMENT 


Element 

•esff'otiotj 

Value 

1 

Connunication  Network 

1 -Voice  2-ATDL 

2 

2 

Acknouledgenent  Required 

1  -  Tes  2  -  No 

2 

3 

Unused 

— 

4 

ATDL  Code  (Unused) 

S 

•  Tint  Message  Sent 

— 

A 

•  Message  Nunber 

— 

7 

•  Sender  CRN 

— 

« 

Sender  Operator  Type 

3 

9 

Sender  Systen  Module  Type 

10 

Task  Node  Nunber  Sent  Fron 

“ 

*  Must  be  set  at  the  tin*  the  nessage  is  sent 


SlBMCTll 


1 

n 


VARIABLE  MESSAGE  FORMAT 

#WORDS  -  1 

HTRACK  column  number  of  track  that  fire  unit  is 
unable  to  get  a  lock  on 


MESSAGE  SUBTYPE  DESCRIPTION 
Acknowledge  Message  -  "Can't  Comply" 


Nines  Riley  Goodin 

Date:  12/20/83 

Systen  Module!  IHAWK 

Project:  MCPADS 

Fron 

To 

Fron 

To 

IHAWK( 25 ) 

BN{ 26) 

X— 2  44- 


e 

NOPADS  MESSAGE  DESCRIPTION 


5 


Message  No.  16 

MESSAGE 

ID  ELEMENT 

*»?»1  Of  1 

Llenent 

Description 

Value 

f  • 

1 

•  Receiver  CRN 

£ 

2 

Operator  Tyoe 

1 

3 

Functional  Type 

3 

5w 

4 

Message  Subtype 

9 

5 

Message  Priority 

3 

*! 

v* 

NESSASE  DATA  LINK  ELEMENT 

Elenent 

Desrnotion 

Value 

*x 
*  » 

I 

Communication 

Network 

*• 

1-Voiee 

2-ATDL 

2 

2 

Acknouledgenent  Required 

s 

1  -  Yet 

2  -  No 

2 

V 

3 

Uaused 

— ■ 

4 

ATDL  Code  (Unused) 

— 

S 

•  Tine  Message  Sent 

-- 

6 

•  Message  Nunber 

— 

7 

*  Sender  CRN 

— 

1 

Sender  Operator  Type 

3 

\\ 

9 

Sender  Systen  Module  Type 

U 

10 

Task  Node  Nunber  Sent  Fron 

“ 

9 

*  Nutt  be  set  at 

the  tine  the  nes, 

.age  is  sent 

‘/•V 

VARIABLE  MESSAGE  FORMAT 

Elenent 

Description 

1 

#VORDS  *  2 

t 

2 

copy  row  number 

of  fire  section 

p 

3 

FS  A  *  1 

V.' 

FS  B  *  2 

MESSAGE 

SUBTYPE  DESCRIPTION 

>v 

TV  back 

in  action  after  missile  reloading 

Mane:  Si 

ley  Goodin 

Systen  Modules  IHAWK 

iV' 

(tat,,  12/20/83 

Projects  MOPADS 

Fron  1 

To 

Fron 

Tc 

> 

3i;U) 

1 

■ 

r ' 
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MOP AOS  MESSAGE  DESCRIPTION 


Message  No.  17  MESSAGE  IS  ELEMENT  Page  ^  pf^- 


LLumi 

1 

2 

3 

4 
s 

* 

Description 

Receiver  CRN 

Operator  Type 

Functional  Type 

Message  Subtype 

Message  Priority 

Value 

1 

-20 

MESSAGE  DATA  LINK  ELEMENT 

Element 

Description 

Value 

1 

Connumcation  Network 

1 -Voice  2-ATDL 

2 

2 

Ackrowledgenent  Required 

I  -  tes  2  -  No 

2 

3 

Unused 

— 

4 

ATDL  Code  (Unused) 

— 

5 

• 

Tine  Message  Sent 

— 

A 

» 

Message  Nunber 

— 

7 

• 

Sender  CRN 

— 

8 

Sender  Operator  Type 

Aircraft 

f 

Sender  Systen  Module  Type 

l.fc 

10 

Task  Node  Nunber  Sent  Fron 

" 

*  Must  t>*t  set  at  the  tine  the  nessage  is  sent 

VARIABLE  MESSAGE  FORHAT 

Elenent 

Description 

1 

#WOKDS  * 

=  0 

MESSAGE  SUBTYPE  DESCRIPTION 


You  are  dead  message  -  sent  from  CONTPV  I.  SYSTEM  MODULE  to  all 
operators  in  the  destroyed  AD  system  module 


Nane:  Piley  Goodin 

Date,  12/20/83 

Systen  Module,  C*«TRL 

Project,  M0PADS 

Fron 

To 

Fron 

To 

CCTRL 

IHAWK 

CNTRL 

GROUP 

C1IT.HCL 

BN 

.V.'  mTCW-  -*5~  J3sr^»r.-rrvr  nss**3au!*i:.rn-« 


s 


A 

»r. 


E? 


v. 


r. 


MOPADS  MESSAGE  DESCRIPTION 


Message  No.  18  MESSAGE  ID  ELEMENT  Page  1  of  1 


Element 

* 

£esf  r  jptioij 

vans 

1 

3 

2 

3 

1 

2 

3 

4 

5 

Receiver  CRN 

Operator  Type 

Functional  Type 

Message  Subtype 

Message  Priority 

MESSAGE  DATA  LINK  ELEMENT 

Element 

^srriptioii 

Value 

1 

Connunication  Network 

1 -Voice  2-ATDL 

2 

2 

Acknowledgement  Required 

1  -  Yes  2  -  No 

2 

3 

Unused 

- 

4 

ATDL  Code  (Unused) 

- 

5 

* 

Tine  Message  Sent 

- 

L 

• 

Message  Nunber 

- 

7 

* 

Sender  CRN 

- 

0 

Sender  Operator  Type 

3 

y 

Sender  System  Module  Type 

k 

10 

Task  Node  Nunber  Sent  From 

- 

*  Must  be  set  at  the  tine  the  message  is  sent 

VARIABLE  MESSAGE  FORMAT 

Element 

Description 

1 

#WORDS 

=  0 

MESSAGE  SUBTYPE  DESCRIPTION 

FU  expended  all  hot  missiles.  This  alert  is  followed  by  an 
inactive  period  during  which  reloading  may  occur. 


Name:  Rilfey  Goodin 

Date:  12/20/83 

System  Module:  IHAWK 

Project:  M0PACS 

F  ron 

To 

From 

r  - 

To 

I HAWK ( 10 ) 

BN ( 22 ) 

X- 247 


f 


HCPASS  MESSAGE  BESCRIPTIOM 


RMaaarjranwa  rsi 


Message  No.  19  MESSAGE  ID  ELEMENT  Page  1  ofl 


Elen tut 

|fscriot»on 

Value 

1 

3 

3 

+2 

1 

2 

3 

4 

5 

*  Receiver  CRN 

Operator  Type 

Functional  Type 

Message  Subtype 

Message  Priority 

MESSAGE  DATA  LINK  ELEMENT 

Elenent 

Description 

Value 

1 

Communication  Network 

1-Voice  2-ATDL 

2 

2 

Acknowledgenent  Required 

1  -  Tes  2  -  Mo 

2 

3 

Unused 

- 

4 

ATDL  Code  (Unused) 

— 

5 

•  Tine  Message  Sent 

- 

6 

•  Message  Nunber 

• 

7 

*  Sender  CRH 

0 

Sender  Operator  Type 

3 

t 

Sender  Systen  Module  Type 

*  l» 

10 

Task  Node  Nunber  Sent  Fro* 

*  Must  be  set  at  the  tine  the  nessage  is  sent 

VARIABLE  MESSAGE  FORMAT 

Element 

Dfsp_r»Pt  Jon 

1 

WORDS  =  2 

2 

NTRACK  column  number  of  target 

3 

=  1  Kill 

*  2  No  Kill 

MESSAGE  SUBTTPE  DESCRIPTION 


FU  effective-tells  the  Q-73  vhether  the  FU  successfully- 
engaged  the  indicated  target 


Nane:  Riley  Goodin 

Date:  12/20/83 

Systen  Module:  IiuiWK 

Project:  MOPADS 

Fron 

To 

Fron 

To 

■  HAVTKl  lli ) 

liiTT) 

/'i 

V-^s 


i 


3 


.^73 
,  "  • 

\  *  .  * 

% 

<*. 

V* 
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HOPAKS  MESSAGE  DESCRIPTION 


ht»nji  No.  20  MESSAGE  III  ELEMENT  Pa?*  1  of  1 


LLpiihI 

Descriot ion 

WHS 

i 

*  Receiver  CRN 

- 

2 

Operator  Type 

1 

3 

Functional  Type 

3 

4 

Message  Subtype 

4 

S 

Message  Priority 

+5 

MESSAGE  DATA  LINK  ELEMENT 


Elenent 

Destruction 

Value 

t 

Connumcation  Network 

1-Voice  2-ATDL 

2 

2 

Acknouledgenent  Required 

1  -  Tes  2  -  No 

2 

3 

Unused 

- 

4 

ATDL  Code  (Unused) 

- 

5 

•  Tine  Message  Sent 

- 

6 

•  Message  Nunber 

- 

7 

•  Sender  CRN 

- 

8 

Sender  Operator  Type 

3 

9 

Sender  Systen  Module  Type 

k 

10 

Task  Node  Nunber  Sent  Fron 

— 

*  Must  be  set  at  the  tine  the  nessa?*  is  sent 


VARIABLE  MESSAGE  FORMAT 

ges^riptiojj 

■ 

WORDS  =  1 

■ 

IJTRACK  column  nunber 

MESSAGE  SUBTYPE  DESCRIPTION 


FU  self-initiated  an  Engagement  (Alert  93) -Notifies  the  0-73 
that  the  FJ  is  engaging  a  pop-up  target. 


Nane:  Jack  Walker 

Dates  8/U/T3 

Systen  Module:  IHAWK 

Project:  MOPADS 

Fron  1 

To 

Fron 

To 

HA'"<(  33) 

BT  1(22) 

MOPADS  MESSAGE  DESCRIPTION 


Message  No. 

21 

MESSAGE 

ID  ELEMENT 

Pag*  l  ofl 

Element 

Descr 

iotion 

Value 

1 

•  Receiver  CRN 

2 

Operator  Type 

3 

3 

Functional  Type 

2 

4 

Message  Subtype 

1 

S 

Message  Priority 

-5.5 

MESSAGE  DATA  LINK  ELEMENT 

Elenent 

Description 

1 

Connumcation 

Network 

1-Voice 

2-ATDL 

l 

2 

| 

Acknouledgsnent  Required 

I 

1  -  Yes 

2  -  No 

2 

3 

j 

Unused 

•* 

4 

ATDL  Code  (Unused) 

S 

•  Tine  Message  Sent 

mm 

6 

•  Message  Nunber 

mm 

7 

i 

*  Sender  CRN 

mm 

8 

' 

Sender  Operator  Type 

5 

? 

Sender  Systen 

Nodule  Type 

k 

10 

Task  Node  Nunber  Sent  Fron 

- 

*  Must  bo  set  at 

the  tine  the  nessage  is  sent 

VARIABLE  MESSAGE  FORMAT 

Element 

Description 

1 

#WORDS  =  1 

2 

NTRACK  Column  Number 

(Track  to  be  pre-empted) 

MESSAGE 

SUBTYPE  DESCRIPTION 

Request  permission  to  cancel  T 

CC  alert-ASO  has  found  a  higher  1 

priority  target.  (Coupled  with  Message  22) 

1  Hanes  Eiley  Goodin 

Svsten  Modules  IHAWK 

Bates  8/U'83 

Projects  M0PADS 

Fron 

To 

Fron 

To 

ASO(4)  ; 

TC0(32) 

HOPADS  MESSAGE  DESCRIPTION 


Message  No.  22 

ElMT.nl  I 


MESSAGE  ID  ELEMENT 


Receiver  CRN 
Operator  Type 
Functional  Type 
Message  Subtype 
Message  Priority 

MESSAGE  DATA  LINK  ELEMENT 


Communication  Network 
1-Voice  2-ATDL 

Acknowledgement  Required 
1  -  Yes  2  -  No 

Unused 

ATDL  Code  (Unused) 

Tine  Message  Sent 
Message  Njnber 
Sender  CRN 

Sender  Operator  Type 
Sender  Systen  Module  Type 
Task  Node  Nunber  Sent  Fron 


*  Must  be  set  at  the  tine  the  message  is  sent 


ElMg.il 

1 


Pag*  l  of  1 
Value 


VARIABLE  MESSAGE  FQRHAT 

Element 

Description 

1 

2 

WORDS  =  1 

I'.TRACK  Column  number 

Cancel 

pre-emp 

MESSAGE  SUBTYPE  DESCRIPTION 

TCC  alert  order  -  TCO  ck's  the  ASO  forgetting  about  a 
ted  track  (coupled  with  Message  21 ) 

Name:  Riley  Goodin 

Date:  8A/83 

Systen  Module:  IHAWK 

Project:  MOPADS 

HOPADS  MESSAGE  DESCRIPTION 


Message  No.  23  MESSAGE  ID  ELEMENT 

Page  l  of  i 

Sl&a&al 

Descriotion 

Value 

1 

*  Receiver  CRN 

mm 

2 

Operator  Type 

b 

3 

Functional  Type 

3 

< 

Hessage  Subtype 

5 

5 

Message  Priority 

-5 

MESSAGE  DATA  LINK  ELEMENT 


Elg.gg.nl 

1 


Description 
Connumcation  Network, 
1-Voice  2-ATDL 

Acknowledgenent  Required 
1  -  Tec  2  -  No 

Unused 

ATDL  Code  (Unused) 

Tine  Message  Sent 
Message  Nunber 
Sender  CRN 

sender  Operator  Type 
Sender  Systen  Module  Type 
Task  Node  Nunber  Sent  Fron 


(WORDS  =  1 

NTRACK  Column  ITunsber  for  New  Track 


Value 

1 

1 


•  Must  be  set  at  the  tine  the  nessage  is  sent 

VARIABLE  MESSAGE  FORMAT 
Elenent  1  Description 


MESSAGE  SUBTYPE  DESCRIPTION,! 

Alert  the  TCA  of  a  new  ASO  target  (coupled  yith  Message  2b) 


Nane:  Hiley  Goodin 

Dates  8/U/83 

Systen  Module:  IHAWK 

Project:  MOP ADS 

Fron 

To 

Fron 

.. 

TCA(1 


M0PADS  MESSAGE  DESCRIPTION 


Message  Ko.  2L 


Lima  t 


MESSAGE  ID  ELEMENT 
IHC  * i  P t  i  PM 


Receiver  CRN 
Operator  Typt 
functional  Typo 
Message  Subtypo 
Doiu^i  Priority 


Value 


5 
k 

6 
*3 


Lima! 

i 


3 

4 

5 
A 
7 
9 
9 

10 


I 


MESSAGE  DATA  LINK  ELEMENT 

Itimaiiaa 

Connunication  network 
1-Voieo  2-ATDL 

Acknowledgement  Required 
1  -  To*  2  -  No 

Unused 

ATDL  Code  (Unused) 

Tine  Message  Sent 
Message  Nunber 
Sender  CRN 

Sender  Operator  Typo 
Sender  Systen  Module  Type 
Task  Node  Nunber  Sent  f r on 


Value 

1 

? 


a 

L 


•  Must  be  set  at  the  tine  the  nessaoe  is  tent 


VARIABLE  MESSAGE  FORMAT 


Lima! 


1 

o 


Description 

/WORDS  *  2 

Message  Number  Acknowledging  (internally  assigned  no. 
NTF.ACK  Column  Nunber 


MESSAGE  SUBTYPE  DESCRIPTION 

Acknowledge  new  ASO  target  (coupled  with  Message  2:) 


Nane;  Rilc^  Goodin 
Dates  8/14/83 


Systen  Module:  IHAWK 
Proiect:  MOPADS 


Fron 


To 


ASO(b) 


Fron 


To 


TCA(IO) 


Mettaif  "I 


MPAH  MESSAGE  KSCtimtM 


RE33ACE  II  ELEMENT 


'*?•  1  «f  1 


llxaiii 

liunmm 

Value 

t 

• 

Receiver  CRN 

2 

Operator  Type 

? 

V 

3 

Functional  type 

3 

4 

Renege  Subtype 

6 

3 

Renege  Priority 

-7 

MESSA6E  647*  LINK  CLEMENT 

LLidiii 

ItKMgtian 

mm 

i 

Cennuaicatioe  Rework 

1 -Voice  2-ATDL 

i 

2 

Acknowledgeiteat  Required 

1  -  lei  2  -  No 

2 

3 

Unuied 

- 

« 

ATDL  Code  (Unuied) 

- 

3 

t 

Tine  Menage  Sent 

- 

4 

• 

Menage  Nun&er 

- 

7 

• 

Sender  CRN 

- 

a 

Sender  Operator  Type 

e  or  7 

» 

Sender  Sytten  Module  Type 

L 

10 

Task  Node  Nunber  Sent  Fron 

• 

*  Nutt  b( 

t  >et  at  the  tine  the  nesiage  it  lent 

VARIABLE  MESSAGE  FORMAT 

Sltaml 

Description 

1 

WORDS 

=  3 

2 

r  IT  RACK  Column  Number 

3 

IHIPIR 

Status :=  1  Lock,  =  2  No  lock' 

h 

Raid  Size:  1-Few,  2-Fev,  3-Many 

MESSAGE  SUBTYPE  DESCRIPTION 

Report 

IHIPIR  Status  to  the  TOO 

Nanej  Pil®y  Goodin 

bate:  8/1+/83 


Fro* 


FCO( 8) 


To 


TCu( 2k) 


Systen  Nodule:  IHAWK 

Project:  MOPADS 

Fron  T  To 


FC0(9)  |TC0(2U) 


-25 


MCPABS  RES SAGE  BESCKIPTION 


hiimt  Ne.  26  MESSAGE  It  EtEMEMT  P*f»  i  at  \ 


LLtatal 

1 

* 

3 

4 

5 

% 

lennotio* 

Receiver  CRM 

Operator  Type 

Functional  Typo 

Message  Subtype 

Message  Priority 

Value 

1 

3 

7 
- 6 

MESSAGE  DATA  LINK  ELEMENT 

Element 

Description 

Value 

1 

Connumcation  network 

1 -Voice  2-ATDt 

2 

2 

Acknouledoenent  Required 

1  -  Tes  2  -  Mo 

2 

3 

Unused 

- 

4 

ATDL  Code  (Unused) 

- 

3 

t 

Tine  Message  Sent 

- 

A 

t 

Message  Nunber 

- 

t 

Sender  CRM 

- 

8 

Sender  Operator  Type 

3 

f 

Sender  Systen  Module  Type 

1* 

10 

Task  Node  Nunber  Sent  Fr on 

•  Must  be  set  at  the  tine  the  nessaoe  is  sent 


VARIABLE  MESSAGE  FORMAT 


Ueae.il 


fc&EELi&ligJ 


1  iFKOP.DS  =  1 

2  KTRACK  column  number 


MESSAGE  SUBTYPE  DESCRIPTION 

Ready  to  Fire  Message  (HAWK  to  BN  Only)  (Coupled  with 
Message  b  from  Q-T.) 


Mane:  Riley  Goodin  Systen  Modules  IHAWK 

Oates  11/8/83  Projects  MOPADS 


Fron 

To 

Fron 

To 

nggygjimH 

BN (22) 

L  i 

Eleatnl 


KJAKS  MESSAGE  BESCIIPTICH 


miitjiNi  27  BESSABE  II  ELEMENT 


lii&miiis 

a  Receiver  CBN 
Operator  Type 
Functional  Typt 
Kmt)t  Subtype 
Kiinjt  Priority 


MESSAGE  BATA  LINK  ELEMENT 


turnption 
Connuaication  Network 
1 -Voice  2-ATDL 
Acknowledgement  Required 
1  -  It*  2  -  No 
Unused 

ATDL  Code  (Unuitd) 
a  Tin*  Message  S«nt 

•  Message  Nunetr 

•  Stndtr  CRN 

Sender  Operator  Type 
Sender  Systen  Module  Type 
Task  Node  Nunber  Sent  Fron 


a  Must  be  set  at  the  tine  the  nessage  is  sent 


VARIABLE  MESSAGE  FORMAT 


Elewent 

I 


f»f*l  of  1 


Value 


Mm 

1 

2 


6  or  7 

h 


LLcj-mi 


DWORDS  =  1 
NTRACK  Column  Number 


MESSAGE  SUBTYPE  DESCRIPTION 

Temporary  No  Kill  Message  -  FCO  then  waits  for  a  Method  of 
Fire  Command  (Subtype  1*0  or  an  order  No  Kill  Command  (subtype 
15) 


Riley  Goodin 

8A/83 


Systen  Module:  IHAWK 

Project:  MOPADS 


Fron 

To 

FCO(lU) 

TCO(32) 

POPAM  MESSAGE  BESCRJPT10M 


Mii>5>  Ha.  23  MESSAGE  1#  EtEftEM!  Pay*  l  af  1 


£l#«f"t 

• 

••script:?* 

Value 

«• 

6  or  7 

1 

U 

*U 

1 

2 

3 

4 

5 

Receiver  CRN 

Operator  Type 

Functional  Type 

Message  Subtype 

Message  Priority 

MESSAGE  SATA  LINK  ELEMENT 

Element 

•ascription 

Value 

1 

Connumcatioa  Network 

1-Voice  2-ATDL 

2 

2 

Acknouledgenent  Required 

1  -  Tes  2  -  No 

2  * 

3 

Unused 

- 

4 

ATSL  Code  (Unused) 

a. 

S 

« 

Tine  Message  Sent 

- 

4 

t 

Message  Nunber 

• 

7 

a 

Sender  CRN 

• 

Sender  Operator  Type 

3 

? 

Sender  Systen  Nodule  Type 

U 

10 

Task  Node  Nunber  Sent  Fron 

- 

*  Must  be  sat  at  the  tine  the  nessage  is  sent 


VARIABLE  MESSAGE  FORMAT 


Element 

tescri2tipij 

1 

u. 

#WOHDS  =  2 

2 

ji  LiTRAGK  Column  Number 

3 

Manual  or  Automatic  Lock  =  1  Manual,  2-Automatic 

[j  -p  ~t~  f—  ip  — r  rr  .  -  „TT-  ^  ^  - _ 

MESSAGE  SUBTYPE  DESCRIPTION 

Assign  nev  target  -  TCO  task  nodes  18?  or  171  cause  a  sending 
of  this  message 


Nane: 

Riley  Goodin 

Systen  Module: 

XHAWK 

Date: 

8A/83 

Project: 

MOFADS 

Message  Me.  30  MESSAGE  IB  ELEMENT 

P»ft  i  af i 

Uiflial 

Beseriptiot 

Value 

i 

•  Receiver  CRN 

- 

2 

Operator  Type 

6  or  7 

3 

Functional  Type 

1 

4 

Message  Subtype 

11* 

S 

Message  Priority 

*6 

NESSA6E  BATA  LINK  ELEMENT 

E  Lin  mi 
» 


ImngJUia 

Connunication  Network 
1-Voice  2-ATDl 

Acknowledgment  Required 
1  -  It*  2  -  No 

Unused 

ATDL  Cod*  (Unustd) 

Tint  Message  Stnt 
Message  Nunber 
Sender  CRN 

Sender  Operator  Type 
Sender  Systen  Module  Type 
Task  Node  Nunber  Sent  Fron 


*  Must  be  set  at  the  tine  the  .tossage  is  sent 


VARIABLE  MESSAGE  FORMAT 


Eli."  ml 


Mill 


DWORDS  =  2 

NTRACK  Column  Number 

Method  of  Fire  =  1  Shoot-Look-Shoot,  2  Ripple  Fire 


MESSAGE  SUBTYPE  DESCRIPTION 

Method  of  Fire  Command  -  Shoot-Look-Shoot  means  shoot  one  then 
evaluate  before  shotting  another.  Ripple  means  shoot  two 
missiles 


Riley  Goodin 


Bate:  8/ll/83 


Systen  Module:  IHAWK 

Project:  MOPADS 


NOP ASS  MESSAGE  DESCRIPTION 


Message  No.  3 2 

MESSAGE  ID  ELEMENT  Pay* 

1  1 

LLcaul 

1 

2 

3 

4 

5 

• 

Description 

Receiver  CRN 

Operator  Type 

Functional  Type 

Message  Subtype 

Message  Priority 

Value 

6  or  7 

1 

16 

-5 

MESSAGE  DATA  LINK  ELEMENT 

SltMtai 

J,f  jcriptjon 

Value 

i 

Connumcation  Network 

1 -Voice  2-ATDL 

1 

2 

Acknouledgenent  Required 

1  -  les  2  -  No 

2 

3 

Unused 

- 

4 

ATDL  Code  (Unused) 

- 

5 

• 

Tine  Message  Sent 

- 

6 

* 

Message  Nunber 

- 

7 

• 

Sender  CRN 

- 

8 

Sender  Operator  Type 

3 

* 

Sender  Systen  Module  Type 

h 

10 

Task  Node  Nunber  Sent  Fron 

- 

*  Must  be  set  at 

the  tine  the  nessage  is  sent 

VARIABLE  MESSAGE  FORMAT 

Element 

Descr  lotion 

1 

WORDS 

=  1 

2 

NT  RACK  Column  Number 

MESSAGE 

SUBTYPE  DESCRIPTION 

Order  FCO  to  Break  Lock 

Nane:  Eile^  Goodin  j 

Systen  Module:  IHAWK 

Date: 

Project:  MOPADS 

Message  Ho.  3U 


EJ  yffjg-2.1 


MOPADS  MESSAGE  DESCRIPTION 


MESSAGE  IS  ELEMENT 


Immlm 

•  Receiver  CRM 
Operator  Type 
Functional  Type 
Message  Subtype 
Message  Priority 


MESSAGE  DATA  LINK  ELEMENT 


*»?•  1  ofi 


Value 


Lisa&al 

i 


Description 
Connunication  Network 
1-Voice  2-ATDL 

Acknowledgenent  Required 
1  -  Tes  2  -  Mo 

Unused 

ATDL  Code  (Unused) 

Tine  Message  Sent 
Message  Nunber 
Sender  CRN 

Sender  Operator  Type 
Sender  Systen  Module  Type 
Task  Mode  Nunber  Sent  Fron 


Mill 


»  Must  be  set  at  the  tine  the  nessage  is  sent 


Lk".g.Pl 


VARIABLE  MESSAGE  FDRHAT 


WORDS  *  1 

Row  number  of  Track  data  of  Track  determined  to  be 
friendly 


MES5AGE  SUBTYPE  DESCRIPTION 


Track  identified  as  friendly 


Nane:  Joe  Polito 
Date:  10/U/83 


Fron 


TCA( 20 ) 


Systen  Module: 
Project: 


IHAWK 

MOPADS 


ifS*jimy+jr9 ^  v« .*■'  r* m~jt\* ».*  -* tm .n* *%* --•  •** *v» 


£ 


i* 

k 

i 


III,  USER  WRITTEN  PROGRAMS 


1- 0  OVERVIEW  OF  THE  FLOW  OF  COKTP.OL 

The  user-vritten  code  for  the  IHAWK  system  module  is 
accessed  via  subroutine  UTHVKW  (called  oy  subroutine  UTASK) . 

These  subroutines  are  divided  into  code  to  be  used  at  first  pre¬ 
decessor  completion  time,  release  time,  start  time,  complete  time 
or  clear  time.  There  are  various  types  of  processing  that  will 
go  on  at  these  different  task  times.  When  a  node  is  being  pro¬ 
cessed,  KSAIXT  calls  subroutine  UTASK.  UTASK  determines  if  it  is 
an  IHAVK  node.  If  sc,  UTASK  calls  UTHVKW.  UTHVKW  then  calls  the 
subroutine  that  performs  processing  for  that  node. 

The  IHAWK  MSAINT  network  regulates  the  flow  of  the  entities 
through  the  task  nodes.  Branching  is  accomplished  either  deter¬ 
ministically  where  the  operator  follows  a  logical  sequence  of 
actions  or  conditionally  where  the  operator  may  do  one  node  verses 
another  node  depending  on  the  state  of  the  system. 

2- 0  EXTERNAL  FILE  USAGE 

There  is  no  direct  external  file  access  in  the  IHAWK  system 
module . 

3- 0  SUBPROGRAM  DESCRIPTIOIIS 

This  section  contains  a  copy  of  the  subprogram  descriptions 
for  each  of  the  IHAWK  user  code  subprograms.  These  subprograms 
are  on  the  following  pages. 


» 


V 

V 

< 

% 

I 


X-261 


u  u  u  a 


SUBROUTINE  ClASOU  UOPP) 


C 

C — NODULE*  MOPADS  1HAUX  SYSTEM  MODULE 
C— REFERENCES  HOPADS  VOLUME  3.1  A 

C**PURPOSE:  THIS  SUBROUTINE  IS  USED  TO  COMPUTE  THE  SCREEN  CLUTTER  FOR 
C  THE  ASO.I1  ALSO  UPDATES  THE  OSV  FOR  SCREEN  CLUTTER. 

C 

CM1NPUT  PARAMETERS*  IOPP-OPERATOR  IB 

e 


SUBROUTINE  CLFCOU  (IOPP) 

C 

C— MODULE*  MOPADS  IHAUX  SYSTEM  MODULE 
C— REFERENCE*  MOPADS  VOLUME  3.16 

C**PURPOSE*  THIS  SUBROUTINE  IS  USED  TO  COMPUTE  THE  SCREEN  CLUTTER  FOR 
C  THE  FCO  AND  UPDATES  THE  OSV. 

C 

C**INPUT  PARAMETERS*  IOPP-OPERATOR  II 
C 


SUBROUTINE  CLTCAU  UOPP) 

C 

C— MODULE*  MOPADS  IHAUK  SYSTEM  MODULE 
C— REFERENCE*  MOPADS  VQLUMC  5.16 

C**PURPOSE*  THIS  SUBROUTINE  COMPUTES  THE  SCREEN  CLUTTER  FOR  TCA  AND 
C  UPDATES  HIS  OSV. 

C 

C**INPUT  PARAMETERS*  IOPP»QPERATOR  ID  ' 

C 


SUBROUTINE  CLTCOU  (IOPP) 

C 

C — MODULE;  MOPADS  IHAUK  SYSTEM  MODULE 
C— REFERENCE!  MOPADS  VOLUME  5.16 

C**PURPQS£*  THIS  SUBROUTINE  IS  USED  TO  COMPUTE  THE  SCREEN  CLUTTER  FOR 
THE  TCO  AND  UPDATES  THE  OSV. 

♦♦INPUT  PARAMETERS*  IOPP=OPERATOR  ID 


X-262 


SUBROUTINE  DCRHSU(IFLA6) 


C—HODULE)  HOPADS  IHAUX  SYSTEM  MODULE 
C — REFERENCE:  HOPADS  VOLUME  5.14 

C**PURPOS£i  THIS  SUBROUTINE  IS  USES  10  DECREASE  MISSILE  COUNTS  UHEN  AN 
C  IHAUK  MISSILE  IS  FIRED  FROM  THE  LAUNCHER. 

C 

C**OUTPUT  PARAMETERSi  IFIAG*0  If  MORE  HOT  MISSILES  REMAIN  ON  THE 
C  SELECTED  LAUNCHER 

C  *1  IF  SELECTED  LAUNCHER  iS  OUT  OF  HOT 

C  MISSILES 

C  >2  IF  ALL  HOT  MISSILES  ARE  EXPENDED 

C 


SUBROUTINE  DEADU(IOPT,IDOPP,NPLACE> 

C 

C— MODULE:  HOPADS  IHAUK  SYSTEM  MODULE 
C— REFERENCE)  HOPADS  VOLUME  S.U 

C**PURPOS£t  THIS  SUBROUTINE  IS  USED  TO  CHECK  IF  THE  HAUK  HAS  BEEN 
C  DESTROYED  OR  ALL  THE  MISSILES  HAVE  BEEN  EXPENDED  FOR 

C  BOTH  FIRE  SECTIONS. 


C**INPUT  PARAMETERS) 
C 

c 


IOPUDEAD  NODE  TYPE 

>1  IF  HAUK  IS  DESTROYED 
•2  IF  BOTH  FIRE  SECTIONS  HAVE 
EXPENDED  ALL  MISSILES 
IDOPP'OPERATOR  ID 
NPLACE'TASK  OCCURRENCE  TIME 


SUBROUTINE  FNDOPU  UQPRTY, ICDPRN, NTASKN,ID) 

C 

C — MODULE)  HOPADS  IHAUK  SYSTEM  MODULE 
C — REFERENCE)  HOPADS  VOLUME  5.16 

C**PURPGSE)  THIS  SUBROUTINE  UILL  FIND  THE  TASK  HUMBER  A  PARTICULAR 
C  HAUK  OPERATOR  IS  AT  AND  UILL  RETURN  THE  ID  OF  THAT  OPERATOR 

C 


X— 263 


CMlNfUT  PARAMETERS  i 

C 

C 

C 

C 

C 

C 

C 


10PSTY-HAUK  OPERATOR  TYPE 
>3  TCO 
-4  TCA 
-3  ASO 
•6  FCO  A 
«7  FCO  B 

ICOPRN^COPY  ROU  NUMBER 


C*»OUTPUT  PARAMETERS!  NTASKN«TASK  NUMBER  OPERATOR  10PRTY 
C  ID*THAT  OPERATOR'S  IB 

C 


IS  AT 


SUBROUTINE  GEVALU(ID0PfNADS*,NC0PI,NGS,10PRfGS,NNG) 

C— MODULE!  HOPABS  I H AUK  SYSTEM  MODULE 
C— REFERENCE:  MOPADS  VOLUME  3.16 
C— PURPOSE: 

C  6EVALU  UILL  EVALUATE  AN  OPERATOR'S  GOAL 

C  FOR  THE  IHAUK. 

C 

C— INPUT  PARAMETERS: 

C  IDOP-OPERATOR  IB 

C  N4DSM-SYSTEM  MODULE  TYPE 

C  NCOPI-COPY  ROU  NUMBER 

C  NSS-ACTUAL  LENGTH  OF  GS 

C— INPUT/OUTPUT  PARAMETERS: 

C  I0PR(2)-DBAA  OF  THE  OPERATOR  STATE  VECTOR 
C — OUTPUT  PARAMETERS: 

C  GS(NGS)-GOAL  STATE  VECTOR 

C  NHG-THE  NUMBER  OF  GOALS  THE  OPERATORS  OF  THE  SYSTEM  HAVE. 

C  (I.E.  ONLY  THE  FIRST  MNG  ELEMENTS  OF  GS  HAVE  MEANINGFUL 

C  INFORMATION).  IF  THE  OPERATOR  DOES  NOT  HAVE  GOAL  I, 

C  THEN  GS(I)»-1.E10. 


STAlk 


VECTOR 


I 


SUBROUTINE  6£V1U< IDOP.NCOPI f 10PR, GS1 )  | 

C— MODULE:  MOPADS  IHAUK  SYSTEM  MODULE 
C~ REFERENCE:  MOPADS  VOLUME  5.16 
C— PURPOSE: 

C  GEV1U  UILL  EVALUATE  GOAL  1  FOR  THE  IHAUK.  60AL  1  IS  ATTACK 
C  ASSIGNED  TRACKS. 

C— INPUT  PARAMETERS: 

C  IDOP-OPERATOR  ID 

C  NCOPI-COPY  ROU  NUMBER  OF  THE  OPERATOR 

C — INPUT/OUTPUT  PARAMETERS: 

C  I0PR(2)-DiAA  OF  THE  OPERATOR 


X-264 


C — OUTPUT  PARAMETERS* 

C  GST -GOAL  STATE  FOR  GOAL  t 


SUBROUTINE  GEV2U(ID0P,NC0PI,I0PRf GS2) 

C — MODULE*  MOPADS  IHAUK  SYSTEM  MODULE 
C — REFERENCE!  MOPADS  VOLUME  3.14 
C— PURPOSE* 

C  GEV2U  DILL  EVALUATE  GOAL  2  FOR  THE  IHAUK.  GOAL  2  IS  SELF 
C  DEFENSE. 

C— INPUT  PARAMETERS* 

C  IDOP-OPERATOR  ID 

C  NCOPI-COPY  RQU  NUMBER  OF  THE  OPERATOR 

C— INPUT/OUTPUT  PARAMETERS* 

C  I0PR(2)-DBAA  OF  THE  OPERATOR 

C— OUTPUT  PARAMETERS* 

C  GS2-G0AL  STATE  FOR  GOAL  2 


SUBROUTINE  G£V3U(IDOP,NCOPIrIOPR,OS3> 

C — MODULE:  MOPADS  IHAUK  SYSTEM  MODULE 
C— REFERENCE*  MOPADS  VOLUME  3.14 
C--PURPOSE* 

C  GEV3U  UILL  EVALUATE  GOAL  3  FDR  THE  IHAUK.  GOAL  3  IS 
C  PROTECT  CRITICAL  ASSETS. 

C— INPUT  PARAMETERS* 

C  IDOP-OPERATOR  ID 

C  NCOPI-COPY  ROU  NUMBER  OF  THE  OPERATOR 

C— INPUT/OUTPUT  PARAMETERS* 

C  IQPR(2)-PBAA  OF  THE  OPERATOR 

C— OUTPUT  PARAMETERS: 

C  GS3-G0AL  STATE  FOR  GOAL  3 


SUBROUTINE  GEV4U(ID0P,NC0PI,I0PR,6S4> 

C — MODULE:  MOPADS  IHAUK  SYSTEM  MODULE 
C— REFERENCE*  MOPADS  VOLUME  5.16 
C — PURPOSE* 

C  GEV4U  UILL  EVALUATE  GOAL  4  FOR  THE  IHAUK.  GOAL  4  IS 
C  IDENTIFY  TRACKS 

C — INPUT  PARAMETERS* 

C  IDOP-OPERATOR  ID 

C  NCOPI-COPY  ROU  NUMBER  OF  THE  OPERATOR 

C— INPUT/OUTPUT  PARAMETERS* 

C  IOPR (2) -DBAA  OF  THE  OPERATOR 

C— OUTPUT  PARAMETERS* 

C  604-GOAL  STATE  FOR  GOAL  4 
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SUBROUTINE  GEV5U(IDQP,NC0PI, I0PR,GS5) 

C— MODULE:  NOPADS  IHAUK  SYSTEM  NODULE 
C—  REFERENCE*  NOPADS  VOLUME  5.16 
C— PURPOSEi 

C  6EV5U  UILL  EVALUATE  GOAL  5  FOR  THE  IHAUK.  GOAL  5  IS 
C  RECEIVE  HESSAGES. 

C— INPUT  PARAMETERS! 

C  IDOP-OPERATOR  ID 

C  NCOPI-COPY  ROU  NUMBER  OF  THE  OPERATOR 

C— IHPUT/OUTPUT  PARAMETERS* 

C  I0PR ( 2> - DBAA  OF  THE  OPERATOR 

C— OUTPUT  PARAMETERS! 

C  6S5-60AL  STATE  FOR  GOAL  5 


SUBROUTINE  GEV6U(ID0PfNC0PI,I0PR,GS6) 

C— MODULE!  HOPADS  IHAUK  SYSTEM  NODULE 
C— REFERENCE:  HOPADS  VOLUME  5.16 
C— PURPOSE* 

C  GEV6U  UILL  EVALUATE  GOAL  6  FOR  THE  IHAUK.  60AL  6  IS 
C  MAXIMIZE  MISSILES. 

C— IHPUT  PARAMETERS! 

C  IDOP-OPERATOR  ID 

C  NCOPI-COPY  ROU  NUMBER  OF  THE  OPERATOR 

C— INPUT/OUTPUT  PARAMETERS! 

C  I0PR(2)-DBAA  OF  THE  OPERATOR 

C— OUTPUT  PARAMETERS! 

C  GS6-G0AL  STATE  FOR  GOAL  6 


SUBROUTINE  GEV7U < IDOP r NCOPI , I  OPR r GS7 ) 

C-NODULE!  MOPADS  IHAUK  SYSTEM  MODULE 
—REFERENCE!  MOPADS  VOLUME  5.16 
—PURPOSEi 

GEV7U  UILL  EVALUATE  GOAL  7  FOR  THE  IHAUK.  GOAL  7  IS 
PROTECT  FRIENDS 
—INPUT  PARAMETERS! 

IDOP-OPERATOR  ID 

NCOPI-COPY  ROU  NUMBER  OF  THE  OPERATOR 
-INPUT/OUTPUT  PARAMETERS! 

IOPR(2>  —  DBAA  OF  THE  OPERATOR 
-OUTPUT  PARAMETERS! 

GS7-GOAL  STATE  FOR  GOAL  7 


SUBROUTINE  3EV8UI irO?,NUO?I, IOPR, GS8) 

C—HODULE;  HOPAB3  IHAUK  SYSTEM  NODULE 
C — REFERENCE*  NOPADS  VOLUME  CJ4 
C— PU«POCE» 

C  5cV8U  U*Ll  IVALUhTL  GUAL  8  riR  THE  IHAUK.  GOAL  8  IS 
C  hINIHZiE  CUAP  J*LY  TARGETS. 

C — INPUT  PARAMETERS! 

C  IDLP-OPERATOR  ID 

C  NCOPI-rOPT  kQU  NUMBER  OP  VHE  OPERATOR 

C— XNPUT/OUTPUT  PARAMETERS! 

C  I0PR(2)-DBAfc  OF  THE  OPERATOR 

C— OUTPUT  PARAMETERS- 
C  8SB-60AL  STATE  FOR  GOAL  8 


SUBROUTINE  HAUKEU(KODE) 

C— MODULE!  HOPADS  IHAUX  SYSTEM  HODULF 
C— REFERENCE!  HOPADS  VOLUME  5. IS 
C— INPUT  PARAMETERS! 

C  HAUKEU  PERFORMS  SPECIAL  EPROR  PROCESSING  FOR  HOPADS  ERROR 

C  CODES  4000-499?  UKICK  ARE  GENERATED  IN  THE  IHAUK  SYSTEM 

C  MODULE  CODE 

C— INPUT  PARAMETERS! 

C  KODE -ERROR  CODE  VALUE 


FUNCTION  IDLCKU  (NTRKCL, ICOPRN) 

C 

C— MODULE:  MOPABS  IHAUK  SYSTEM  MODULE 
C— REFERENCE!  HOPADS  VOLUME  5.16 

CMPURPOSEt  THIS  FUNCTION  IS  USED  TO  DETERMINE  IF  1HIP1R  LOCK  UAS 
C  ACHEIVED. 

C 

CMIKPUT  PARAMETERS!  NTRKCL=NTRACK  COLUMN  NUMBER  FOR  TRACK  DATA 
C  ICOPRN=OPERATOR  COPT  NUMBER  TRYING  TO  ACHEIVE 

C  .  LOCK 

C 

CMOUTPUT  PARAMETERS!  IDLCKUM  IF  LOCK  UAS  ACHEIVED 
C  >2  IF  LOCK  UAS  NOT  ACHEIVED 

C 


I 
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SB 
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FUNCTION  IFFNU  (IGPP, NTRKCL) 


C— MODULE:  NOPADS  IHAUK  SYSTEM  NODULE 
C—REFERENCE:  NOPADS  VOLUME  5.16 

C**PURPOSE:  THIS  FUNCTION  IS  USED  TO  DETERMINE  THE  IFF  RETURN  WHEN  THE 
C  TCA  CHALLENGES  A  TARGET. 

C 

C«*INPUT  PARANETERSt 
C 
C 

C»*OUTPUT  PARAMETERS! 

C 
C 
C 


IOPPsOPERATOR  It 

NTRKCL-TRACK  COLUMN  NUMBER  IN  NTRACK 

IFFN«»1  HOSTILE 
>2  FRIEND 
>3  UNKNOWN 


SUBROUTINE  INITU(NRUN)  F| 
C— MODULE:  HOPADS  IHAUK  SYSTEM  MODULE  *3 
C—REFERENCE:  MOPADS  VOLUME  S.16 

C— PURPOSE:  i  W 
C  INITU  PERFORMS  INITIALISATION  FOR  THE  IHAUK  SYSTEM  NODULE.  ft 
C— INPUT  PARAMETERS: 

C  HRUN-RUN  NUMBER  r« 
C  O-DO  ONE-TIME  INITIALIZATION  BEFORE  ANY  RUNS  M 
C  N-INITIALIZE  FOR  RUN  N  lJ 


FUNCTION  IRDSZU(NTRKCL) 

C 

C— MODULE:  MOPADS  IHAUK  SYSTEM  MODULE 
C—REFERENCE:  HOPADS  VOLUME  3.16 

C**PURPOSE:  THIS  FUNCTION  IS  USE!  TO  DETERMINE  THE  FCO'S  PERCEPTION 
C  OF  THE  RAID  SIZE. 

C 

C**INPUT  PARAMETERS:  NTRKCLMTRACK  COLUMN  NUMBER  FOR  THE  TRACK 
C 

CMOUTPUT  PARAMETERS:  IRDSZU»1  IF  RAID  SIZE  IS  1 

C  -2  IF  RAID  SIZE  IS  2  OR  3 

C  >3  IF  RAID  SIZE  IS  >  3 

C 


P  * 


k 


I 
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FUNCTION  KILirUUOPP.NTUCL) 


C— NODULE  !  MOPADS  IHAUX  SYSTEM  MODULE 
C— REFERENCE*  HOPADS  VOLUME  5.14 

C«*PURPCSE(  THIS  FUNCTION  IS  USES  TO  DETERMINE  IF  AN  IHAUK  ENGAGEMENT 
C  HAS  EFFECTIVE 

C 

I{'PP*OPERATOR  IS 
NTRKCL'NTRACK  COLUMN  NUMBER 


C**INPUT  PARAHETERSt 

C 

C 

C**OUTPUT  PARAHETERSl 

C 

C 

c 


KILLTU*0  INEFFECTIVE 
>1  EFFECTIVE 
•2  PARTIALLY  EFFECTIVE 


FUNCTION  NFRMSU<IQPRCN,NTRKCU 
C 

C— MODULE i  MOPADS  IHAUX  SYSTEM  MODULE 
C — REFERENCE*  HOPADS  VOLUME  5.14 

C**PURPOSE«  THIS  FUNCTION  EVALUATES  UHEfHER  THE  TCO  SHOULD  ORDER  THE 
C  FCO  TO  PRESS  THE  NO  KILL  DUTTON  OR  TO  FIRE  MORE  MISSILES. 

C 

CMINPUT  PARAMETERS:  10PRCN-C0PY  ROU  NUMBER  OF  THE  TCO 
C  NTRKCL-HTRACX  COLUMN  POINTER  FOR  THE  TRACK 

C 

C«OUTPUT  PARAMETERS:  HFRMSUM  IF  TCC  SHOULD  ORDER  FCO  TO  PRESS  NO  KILL 
C  >2  IF  TCO  SHOULD  ORDER  FCO  TC  FIRE  MORE 

C  MISSILES 

C 


SUDROUTINE  OEA$OU(IDCP,HADSH,NCOPI,GS,NNG, JTASK, IOPR,6SJfTJ> 
-MODULE!  HOPADS  IHAUK  SYSTEM  MODULE 
—REFERENCE!  HOPADS  VOLUME  5.14 
—PURPOSE! 

OEASOU  HILL  COMPUTE  EXPECTED  GOAL  STATES  FOR  THE  IHAUK  ASO 
— INPUT  PARAMETERS! 

1DOP-OPERATOR  I.' 

NADSH-SYSTEM  MODULE  TYPE 
NCOPI-COPY  ROU  NUMBER 
OStNNSI-CURRENT  GOAL  STATE  VECTOR 

JTASK-OPERATOR  TASK  NUMBER  OF  THE  OPERATOR.  OEASOU  U1LL 
EVALUATE  THE  EXPECTED  GOALS  GIVEN  THAT  THE  OPERATOR 
PERFORMS  TASK  JTASK 
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C — INPUT/OUTPUT  PARAMETERS: 

C  IOPR(2)-DBAA  OF  THE  OPERATOR 
C— OUTPUT  PARAMETERS: 

C  GSJ(NNG) -EXPECTED  GOAL  STATES  RESULTING  FROM  TASK  JTACK. 

C  ON  INPUT,  GSJ*GS 

C  TJ-EXPECTED  : IME(MINUTES)  TO  PERFORM  TASK  JTASK.  IF  THE 

C  OPERATOR  CANNOT  PERFORM  OR  DOES  NOT  PERFORM  TASK  JTASK, 

C  THEN  DO  NOT  CHANGE  TJ. 


J 


SUBROUTINE  OEFCCUt IDOP.NADSM, NCOPI,GS,NNG, JTASK, IOPR,GSJ,TJ) 
C— MODULE:  MOPADS  IHAUK  SYSTEM  MODULE 
C— REFERENCE:  MOPADS  VOLUME  3 .14 
C— PURPOSE: 

C  OEFCOU  WILL  COMPUTE  EXPECTED  GOAL  STATES  FOR  THE  IHAUK  FCO 
C— INPUT  PARAMETERS: 

C  IDQP-OPERATOR  ID 

C  NADSM-SYSTEM  MODULE  TYPE 

C  NCOPI-COPY  ROU  NUMBER 

C  6S(NNG)-CURR£NT  GOAL  STATE  VECTOR 

C  JTASK-OPERATOR  TASK  NUMBER  OF  THE  OPERATOR.  OEFCOU  UILL 

C  EVALUATE  THE  EXPECTED  GOALS  GIVEN  THAT  THE  OPERATOR 

C  PERFORMS  TASK  JTASK 

C— INPUT/OUTPUT  PARAMETERS: 

C  10PR(2)-DBAA  OF  THE  OPERATOR 

C— OUTPUT  PARAMETERS: 

C  GSJ(NNG)-EXPECTED  GOAL  STATES  RESULTING  FROM  TASK  JTASK. 

C  ON  INPUT,  GSJ*GS 

C  TJ-EXPECTED  TIME(MINUTES)  TO  PERFORM  TASK  JTASK.  IF  THE 

C  OPERATOR  CANNOT  PERFORM  OR  DOES  NOT  PERFORM  TASK  JTASK, 

C  THEN  DO  NOT  CHANGE  TJ. 


ft 
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SUBROUTINE  OETCAUt IDOP,NADSM,NCOPI,GS,NNG, JTASK, IOPR,GSJ,TJ) 


C— HODULEi  MOPADS  IHAUK  SYSTEM  MODULE 
C--REFERENCE:  MOPADS  VOLUME  5.14 
C— PURPOSE: 


f 


C  OETCAU  UILL  COMPUTE  EXPECTED  GOAL 
C— INPUT  PARAMETERS: 

C  IDOP-OPERATOR  ID 

C  NADSH-SYSTEH  MODULE  TYPE 

C  NCOPI-COPY  ROU  HUMBER 

C  6S(NNG)-CURRENT  GOAL  STATE  VECTOR 

C  JTASK-OPERATOR  TASK  NUMBER  OF  THE 

C  EVALUATE  THE  EXPECTED  GOALS 

C  PERFORMS  TASX  JTASK 


STATES  FOR  THE  IHAUK  TCA 


OPERATOR.  OETCAU  UILL 
GIVEN  THAT  THE  OPERATOR 
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C — IHPUT/OUTPUT  PARAMETERS* 

C  I0PR<2)-DBAA  OF  THE  OPERATOR 
C— OUTPUT  PARAMETERSi 

C  BSJ(NNG)-EXPECTED  GOAL  STATES  RESULTING  FROM  TASK  JTASK. 

C  ON  INPUT,  OSJ*GS 

C  TJ-EXPECTED  TIKE (MINUTES)  TO  PERFORM  TASK  JTASK.  IF  THE 

C  OPERATOR  CANNOT  PERFORM  OR  COES  NUT  PERFORM  TASK  JTASK, 

C  THEN  DO  NOT  CHANGE  TJ. 


SUBROUTINE  OETCOUdDOP, NADSM,NC0PI,GS,NN3, JTASK, IOPR,GSJ,TJ) 
C— MODULE!  MCPADS  1HAUK  SYSTEM  MODULE 
C— REFERENCE*  NOPADS  VOLUME  5.16 
C— PURPOSE! 

C  OETCOU  UILL  COMPUTE  EXPECTED  GOAL  STATES  FOR  THE  IHAUK  TCO 
C— INPUT  PARAMETERS! 

C  IDGP-OPERATOR  ID 

C  NADSM-STSTEN  MODULE  TYPE 

C  NCOPI-COPT  RGU  NUMBER 

C  6S(NN6)-CURREMT  GOAL  STATE  VECTOR 

C  JTASK-OPERATOR  TASK  NUMBER  OF  THE  OPERATOR.  OETCOU  UILL 

C  EVALUATE  THE  EXPECTED  GOALS  GIVEN  THAT  THE  OPERATOR 

C  PERFORMS  TASK  JTASK 

C~ INPUT/OUTPUT  PARAMETERS* 

C  IOPR(2)-DBAA  OF  THE  OPERATOR 

C— OUTPUT  PARAMETERS* 

C  6SJ(NN6) -EXPECTED  GOAL  STATES  RESULTING  FROM  TASK  JTASK. 

C  ON  INPUT,  6S J=GS 

C  TJ-EXPECTED  TIME (MINUTES)  TO  PERFORM  TASK  JTASK.  IF  THE 

C  OPERATOR  CANNOT  PERFORM  OR  DOES  NOT  PERFORM  TASK  JTASK, 

C  THEN  DO  NOT  CHANGE  TJ. 


SUBROUTINE  OEVALUt IDOP,NADSH, NC0PI,GS,NN6, JTASK, IOPR,GSJ,TJ,«) 
C — MODULE*  NOPADS  IHAUK  SYSTEM  MODULE 
C— 'REFERENCE*  HOPADS  VCLUNE  5.16 
C— PURPOSE! 

C  OEVALU  UILL  COMPUTE  THE  EXPECTED  GOAL  STATE  VECTOR  FOR 
C  THE  IHAUK  OPERATORS. 

C— INPUT  PARAMETERS! 

C  IDOP-OPERATOR  ID 

C  NADSH-SYSTEM  MODULE  TYPE 

C  NCOPI-COPY  ROU  NUMBER 

C  GS(NNS) -CURRENT  GOAL  STATE  VECTOR 

C  JTASK-OPERATOR  TA5K  NUMBER  OF  THE  OPERATOR.  OEVALU  UILL 

C  EVALUATE  EXPECTED  GOAL  STATES  GIVEN  THAT  THE 

C  OPERATOR  PERFORMS  TASK  JTASK. 


C — INPUT/OUTPUT  PARAMETERS! 

C  I0PR(2)-DBAA  OP  THE  OPERATOR 
C-rUTPUT  PARAMETERS! 

C  GSJ(NNG>-EXPECTED  GOAL  STATES  RESULTING  FROM  PERFORMING 
C  TASK  JTASK.  ON  INPUT  6SJ=GS. 

C  TJ-EXPECTED  TIME  (MINUTES)  TO  PERFORM  TASK  JTASK.  IF  THE 

C  OPERATOR  CANNOT  PERFORM  OR  DOES  NOT  PERFORM  TASK  JTASK, 

C  THEN  TJ— l. 

C— ALTERNATE  RETURNS! 

C  1-JTASK  IS  GREATER  THAN  THE  HAX1HUH  TASK  NUMBER  THAT  THE  OPERATOR 
C  PERFORMS.  OEVALU  UILL  BE  CALLED  REPEATEDLY  UITH  GREATER 

C  VALUES  OF  JTASK  UNTIL  THIS  CONDITION  OCCURS. 


SUBROUTINE  T— U  (NPLACE) 

C 

C— MODULE!  HOPADS  IHAUK  SYSTEM  MODULE 
C— REFERENCE!  HOPADS  VOLUME  5.16 
C 

C*«PURPOSEi  USER  CODE  FOR  IHAUK  TASK  NODE 
C 

CMINPUT  PARAMETER:  NPLACE  -  TASK  OCCURRENCE  TIME 
C 


— * - THIS  TEMPLATE  IS  T.PICAL  FOR  ALL  TASK  NODE  PROGRAMS 


SUBROUTINE  THR2U(ID0P,NC0PI,JTRK,XLB,TCA,NTRK,ISTAT) 

C— MODULE:  HOPADS  IHAUK  SYSTEM  MODULE 
C — REFERENCE:  HOPADS  VOLUME  5.16 
C— -PURPOSE! 

C  THR2U  UILL  LOCATE  THE  TRACK  THAI  15  MOST  THREATENING  TO 
C  AN  IHAUK.  THIS  SUBPROGRAM  IS  USED  TO  EVALUATE  THE  SELF 

C  DEFENSE  GOAL.  THR2U  UILL  ALSO  EVALUATE  A  SINGLE  TRACK, 

C  BASED  ON  THE  VALUE  OF  JTRK. 

C--IN“UT  PARAMETERS! 

C  IDOP-THE  OPERATOR'S  ID 

C  NCOPI-COPY  ROU  NUMBER  FOR  THE  OPERATOR 
C  JTRK-TRACX  COLUMN  NUMBER  IN  NTRACK 

C  6-EVALUATE  ALL  TRACKS 

C  K-EVALUATE  ONLY  THE  TRACK  IN  COLUMN  K 

C  XLB-LOUER  BOUND  ON  TOA.  THE  TRACK  UITH  THE  MINIMUM  TIME 
C  BUT  GREATER  THAN  XLB  UILL  BE  RETURNED.  XLB  .GT.  0 

C  IS  USED  TO  EXCLUDE  THE  HOST  THREATENING  TRACK  UHEN 

C  ESTIMATING  THE  IMPACT  ON  GOALS  OF  VARIOUS  TASKS. 
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-OUTPUT  PARAMETERS* 

TOA-TIME  OF  ARRIVAL  OF  THE  HDST  THREATENING  TRACK. 
NTRK-NTRACK  COLUMN  OF  THE  MOST  THREATENING  TRACK, 
ISTAT-TRACK  STATUS! SEE  THRU) 


SUBROUTINE  THR3U ( I0QP „ NCUPI , JTRK, n.B,TOA,NTRKf ISTAT) 
-MODULE:  HOPADS  IHAUK  SYSTEM  MODULE 
-REFERENCE*  HOPADS  VOLUME  5.14 
-PURPOSE* 

THR3U  UILL  LOCATE  THE  TRACK  THAT  IS  HOST  THREATENING  TO 
AN  IHAUK'S  PROTECTED  SITES. 

THR3U  UILL  ALSO  EVALUATE  A  SINGLE  TRACK, 

BASED  ON  THE  VALUE  OF  JTRK. 

—  INPUT  PARAMETERS* 

IDOP-THE  OPERATOR'S  ID 
NCOPI-COPY  ROU  NUMBER  FOR  THE  OPERATOR 
JTRK-TRACK  COLUMN  NUMBER  IN  NTRACK 
O-EVALUATE  ALL  TRACKS 
K-EVALUATE  ONLY  THE  TRACK  IN  COLUMN  K 
XLB-LOUER  BOUND  ON  TOA.  THE  TRACK  UITH  THE  MINIMUM  TIME 
BUT  GREATER  THAN  XLB  UILL  BE  RETURNED.  XLB  ,GT.  0 
IS  USED  TO  EXCLUDE  THE  HOST  THREATENING  TRACK  UHEN 
ESTIMATING  THE  IMPACT  ON  GOALS  OF  VARIOUS  TASKS. 
-OUTPUT  PARAMETERS* 

TOA-TIME  OF  ARRIVAL  OF  THE  MOST  THREATENING  TRACK. 
NTRK-NTRACK  COLUMN  OF  THE  MOST  THREATENING  TRACK. 
ISTAT-TRACK  STATUStSEE  THRU) 


FUNCTION  USERFUI ICODE) 

MODULE*  MOPADS  IHAUK  SYSTEM  MODULE 
—REFERENCE*  MOPADS  VOLUME  5.14 
—PURPOSE* 

USERFU  EVALUATES  THE  USER  FUNCTION  FOR  THE  IHAUK 
—  INPUT  PARAMETERS* 

ICODE-USER  FUNCTION  CODE 
--OUTPUT  PARAMETERS: 

USERFU-VALUE  OF  THE  USER  FUNCTION 
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FUNCTION  USERNUt ICODE > 

C--HODULE:  “OPADS  IHAUK  SYSTEM  MODULE 
C— REFERENCE*  MOPADS  VOLUME  f.i* 

C— PUPPOSEl 

i  USERNU  EVALUATES  i HE  INP'JT  USER  FUNCTION  FDR  THE  IHAUK 

C -INPUT  PARAMETERS! 

C  ICODE-USER  FVM.iION  CODE 

C— OUTPUT  PARAMETERS! 

C  USERNU- VALUE  Or  THE  USER  FUNCTION 


FUBR0U7INE  UTHUKU(NT,NPLACE) 

C— KDDULCl  «  ^ADS  IHAUK  SYSTEM  MD'.iLE 
C — REFERtNC..*  MOPADS  VOLUME  5.U 
C— PURPOSE! 

C  UTHUKU  PROCESSES  CALLS  FROM  UTASK  FOR  THE  1HAU* 

C  SYSTEM  MODULE. 

C--INPUT  PARAMETERS! 

C  NT-TASK  NODE  NUMBER 

C  NPLACE-TASK  NODE  OCCUI.RANCE  TINZISEE  UTASK) 
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k-0  ERROR  PROCESSING 
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When  an  error  involving  the  IHAWK  user  code  is  detected  a 
call  is  made  to  subroutine  SERR.  The  only  parameter  thi»  sub¬ 
routine  has  is  the  error  code.  The  numbers  6100  to  6999  aee 
reserved  for  errors  detected  in  the  IHAWK  uier  code.  Ta^le  TII-1 
lists  all  the  error  codes  and  their  definitions. 
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Table  III-l.  IHAWK  Error  Codes  and  Messages 


Error 

Code 

Description 

Programs 

6000 

No  track  was  found  in  data  base  corres¬ 
ponding  to  the  current  track  for  the 

IHAWK  fire  section 

T8W 

6001 

The  current  track  engaged  by  the  HAWK 
does  not  match  the  track  referred  to  in 
the  message. 

T13W 

6002 

Self-clearing  operation  has  failed 

T136W 

6003 

User  clearing  operation  has  failed 

T136W 

6004 

Fire  section  status  does  not  requirp 
the  FC0  to  place  his  fire  section  cut 
of  action. 

T10W 

6005 

FC0  has  received  a  message  from  the  TC0 
to  break  lock  on  a  target  other  than 
his  current  target. 

T16W 

6006 

No  hot  missile^  available  for  launchers. 

T48W 

6007 

Effect  of  current  fire  section  status  on 
FC0  clutter  has  not  been  accounted  for. 

CLFC0W 

6008 

The  track  (changing  from)  was  not  found 
in  the  data  base. 

T16W 

6009 

Too  many  tracks  found  in  data  base. 

T16W 

6010 

Row  does  not  exist  in  data  base  or  it 
does  not  contain  track  data. 

T31W, 

T11QW 

6011 

Not  used 

6012 

Invalid  message  subtype  for  a  Q-73 
message  to  the  TC0. 

TT1W 

6013 

Invalid  message  subtype  for  a  FCO 
message  to  the  TC0. 

T78W 

6014 

Invalid  message  subtype  for  an  AS0 
message  to  the  TC0. 

T79W 

6015 

Cannot  *ind  FCO. 
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Table  III-l.  (continued) 


Error 

Code 

Description 

Programs 

6016 

Unable  to  clear  FC0 

T28W ,T60W, 

T63WJ153W, 

T158W 

6017 

Invalid  message  subtype  for  a 

TCA  message  to  the  TCO. 

T81W 

6030 

Could  not  find  operator  ID  in  NCOPY 
array. 

FNDOPW 

6031 

Could  not  find  operator  at  a  task. 

FNDOPW 

6032 

Operator  not  found  at  appropriate  task 

T31W ,T73W 

6033 

Invalid  operator  type. 

FNDOPW 

6500 

Invalid  user  function  code 

USERFW, 

USERNW 

6501 

No  message  was  found  for  the  ASO 
when  one  was  expected. 

OETCAW 

6502 

Incorrect  message  type  received  by 

TCA. 

OETCAW 

6503 

Incorrect  message  type  received  by 

ASO. 

OEASOW 

6504 

Incorrect  node  number. 

UTHWKW 

6505 

An  attempt  was  made  to  make  a  primary 
assignment  to  a  track  that  already  has 
a  primary  assignment. 

TT1W 
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GEH,IHAUK,9,7,B3,4* 

P0P,4,5, 15, 10,10* 

BIS, 1, CO, 0.0* 

BIS, 2, CO, 0.1* 

BIS, 3, CO, 0.001* 

BIS, 4, CO, 9999.0* 

BIS, 5, CO, 15.0* 

UTI,1,NUNIPAR* 

UTI,2,NUHCL'AR* 

OBO,1, THREAT* 

IRA, 1,3, SC, 1,4, SC, 04 

IRA, 2, 3, SC, 1.4, SC, 0* 

IRA, 3, 3, SC, 1,4, SC, 0* 

IRA, 4, 3, SC, 2, 4, SC, 0* 

IRA, 5, 3, SC, 2, 4, SC, 0* 

IRA, 6, 3, SC, 2, 4, SC, 0* 

LRE,1,ILCHR1A,2,ILCHR2A,3,ILCHR3A,4,ILCHR1B,5,ILCHR2B,6,ILCHR3B* 

11)0,1, A* 

• 

«  SOURCE  TASKS  FOR  THE  IHAUX  SYSTEM  MODULE 

• 

TAS,4S,S0URCTC0,,,BS,1,,,S0* 

UTC, 45, 0.0, 0.0, 1.0* 

MOO, 45, 1 ,0, T* 

BET, 45, 40* 

• 

TAS, 44, SOURCTCA, ,,0S,1,,,S0* 

UTC, 44, 0.0, 0.0, 1.0* 

HOD, 44, 1 ,D, T* 

BET, 46, 40* 

*  ..  '  ^ 

TAS,47,SQURCASl, , , DS, 1 , , ,bO* 

UTC, 47, 0.0, 0.0, 1.0* 

MOD, 47,1, 1»,J* 

BET, 47, 40* 

* 

TAS,4<?, SOURCFCA, ,  ,DS,  1 , ,  ,S0* 

UTC, 48, 0.0, 0.0, 1.0* 

HOD, 48,1 ,D,T* 

BET, 48, 40* 
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TAS, *9,S0URCFCP, , ,DS ,1 , , ,S0» 

UTC, 49, 0.0,0. 0,1. 0* 

«0D,49,1 

CET,49,40* 

* 

•  THIS  COivTitOL  NETWORK  IS  FOR  SCHEDUt  ING  LAUNCHER  DOWNTIME 

•  DUE  TO  REL0ADIN6  HOT  MISSILES 

• 

TAS,134,LCHRDLAY,1,1,DS,5* 

UTC, 134, 0.0, 0.0, 1.0* 

H0D,134,1,D,T* 

•  NO  BRANCH,  TREATED  LIKE  A  SINK  NODE 

• 

•  THIS  NODE  IS  THE  DEAD  NODE,  USED  FOR  REMOVING  OPERATORS 

•  THAT  ARE  NO  LONGER  PART  OF  THE  SIMULATION  (E.G.  HAUK  IS 

•  DESTROYED  (REMOVE  ALL  OPERATORS) , FIRE  UNIT  HAS  EXPENDED 

•  ALL  MISSILES  (REMOVE  THE  CORRESPONDING  FCO) 

• 

TAS,90,DEADN0DE, 1 , 1  ,DS,  1* 

UTC, 90, 0.0,3. 0,1.0* 

H0D,90,t ,D,T* 

•  NO  1RANCH,  ENTITY  IS  DESTROYED 

• 

•  OPERATOR  TASK  t,  ASO  MONITOR  CRT, CONTROLS, INDICATORS 

* 

TAS,t , ASOSTNDB ,  1 , 1 ,DS,1* 

UTC, 1,1.0, 3. 0,1.0* 

DET,1 ,40* 

« 

•  OPERATOR  TASK  2,  DETECT  TARGET  AT  CUTDC 

• 

TAS,2,DTCTCUAR,1 ,1  ,BS,1  * 

UTC, 2, 2. 0,3. 0,1.0* 

DET,2,40* 

* 

*  OPERATOR  TASK  3,  ESTABLISH  TARGET  PRIORITY  (ASO). 

• 

TAS,3,ESTTARPR,1,!,DS,1* 

UTC, 3, 3. 0,1. 0,1.0* 

DET,3,104* 

• 

TA$,104,L0UPRC0F,t,1  ,DS,1* 

UTC, 104, 3. 0,2. 0,1.0, <12)1.0* 

DET,104,40* 
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•  OPERATOR  TASK  4,  PREEMPT  LOUFR  PRIORITY  TARGET  (ASO) 

• 

TAS,4,REQCLRAL,1 ,1 ,DS,1* 

UTC, 4, 4. 0,1. 0,1.0* 

H0D,4,1 ,D,T* 

DET, 4,107* 

• 

TAS,107,UAITTC0H, 1 ,t ,1S,4* 

UTC, 107, 4. 0,0. 0,1.0* 

H0D,»07,1,D,T* 

•  NO  BRANCH, OPERATOR  MUST  IE  CLEARED  TO  TASK  108 

9 

TAS,10B,PRSAICNL,1,1,DS,1* 

UTC, 108, 4. 0,2. 0,1.0, (12)1.0* 

BET, 108,40* 

• 

*  OPERATOR  TASK  S,  TCC  ALERT  (ASO) 

•  * 

TAS. 5, POSCUCRS, 1,1,08,1* 

UTC, 5, 5. 0,1. 0,1.0* 

DET, 3, 109* 

• 

TAS, 100, PHUSLEU, 1,1, 03,1* 

UTC, 109, 5. 0,0.0, 1.0* 

DET ,109,110* 

• 

TAS, 1 10,PRSTCCAB,1,1 ,DS, 1* 

UTC, 113, 3. 0,2. 0,1.0, (12)1.0* 

DET, 110,40* 

• 

•  OPERATOR  TASK  A,  HARK  TARGET  AS  ACCEPTED  BY  TCC  (*.S0) 

• 

TA8,*,0BSVALEX,1,1,DS,1* 

UTC, 6, 4. 0,1. 0,1.0* 

BET, 4, 111*  i 

•  I- 

TAS, 111 ,RRKTARGT,t ,1 ,DS,1* 

UTC, 111, A. 0,2. 0,1.0, (12)1.0* 

DET, 111, 40* 

• 

•  OPERATOR  TASK  7,  FC9  H0N1T0R  CRT, CONTROLS, INDICATORS 

• 

TAS,7,FC0STNDI,t ,1 ,BS,4* 

UTC, 7, 7. 0,3. 0,1.0* 

HOD, 7, 1 ,D, T* 

DET, 7, 40* 


V 


•  OPERATOR  TASK  3,  TRACK  TARGET  (FCO) 

•  . 

TAS,8,DPR0CADP, 1 , 1 ,DS,1* 

UTC, e, 8. 0,1. 0,1.0* 

CFl,8,t20,AEV,2.0,13,lA,,112,A£V,1 .0,13,IA* 

• 

TA3,1 20,uBAjSLTP,1 ,1 ,DS, 1  * 

MTC,'»20.8.0,0.C,1.0* 

8ET, 120,117* 

• 

TAS,1 12,0BSftCHLH,1 ,1 ,DS,1* 

UTC, 112, 8. 0,0. 0,1.0* 

DET ,112,11 3* 

• 

TAS,t 13,DH!PIRLK,1,1 ,UF,2* 

UTC, 113, 8. 0,0.0, 1.0* 

HOD, 113,1, 9, T* 

CFI,113,117,AEU,0.0,14,IA,,113,AEV,1.0,14,!A* 

* 

TAS,1 t3,0IVL0CKL,t , 1 ,DS, 1* 

UTC, 113, 8. 0,0. 0,1.0* 

DET, 113, 117* 

* 

TAS,1 17,ENDTSX08,t ,1 ,9S,3* 

UTC, 117, 8. 0,2. 0,1.0, (12)1.0* 

HOD, 117,1,9,1* 

DET, 117, 40* 

• 

•  OPERATOR  TASK  f,  OBTAIN  HANUAL  HIPIR  LOCX  (FCO) 

• 

TAS,9,P0SC'JRS,1 ,1  ,DS,  1* 

UTC, 9,9. 0,1. 0,1.0* 

DET, 9, 121* 

• 

T AS, 121 ,PRSFLSHE,1 , 1 ,DS. 1* 

UTC, 121, 9. 0,0. 0,1.0* 

DET, 121, 122* 

• 

TAS,122,DCDHIPLK,1 ,1 ,UF,2* 

UTC, 122, 9. 0,0. 0,1.0* 

HOD, 122, 1 ,D,T* 

CFI,122,123,AEV,1 .0,14,IA,,124,AEV,2.0,14,IA* 

* 

TAS,f 23,TAR8ALT,1 ,1 ,DS, I* 

UTC, 123, 9. 0,0. 0,1.0* 

DET, 123, 124* 
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TAS,124,EHDTSK09,1  , 1 ,DS,3* 

UTC, 124,?. 0,2. 0,1.0* 

HOI, 124,1,0,1* 

DEI, 124,40* 

* 

•  OPERATOR  TASK  10,  PUT  FIRE  SECTION  OUT  OF  ACTION  (FCO) 

* 

TAS,10,PSHFS0FF,1 ,1 ,DS,1* 

UTC, 10, 10. 0,1. 0,1.0* 

CFI,10,88,AEV,0.0, 1S,IA, ,B9,AEV, 1 . 0 , 1 S , X A* 

* 

TAS,88,EN0TSKt0,1,1 ,DS,3* 

UTC, 86, 10. 0,2. 0,1. 0,(1 2) 1.0* 

MOO, 88,1 ,D,T« 

BET, 88, 40* 

* 

TAS,8?,UAI7RELD,1 , 1 ,DS,4* 

UTC, 8?, 10. 0,0. 0,1.0* 

HOOF, 89,1 ,D,T* 

«  NO  BRANCH  RUST  BE  CLEARED  TO  TASK  NODE  88 
* 

*  OPERATOR  TASK  11,  ESTIMATE  RAID  SIZE  (FCO) 

* 

T  AS, 1 1 ,NONTOOPA,1,t,OS,t* 

UTC, 11, 11. 0,1. 0,1.0* 

BET, 11, 133* 

• 

TAS, 133,DCDRDSIZ, 1 ,1 ,DS, 1* 

UTC, 133, 11. 0,0. 0,1.0* 

BET, 133, 134* 

• 

TAS,134,PSH0FM,1,1,DS,1* 

UTC, 134, 11. 0,0. 0,1.0* 

BET, 134, 137* 

• 

TAS, 1 37,ENDTSK1 1 ,1 ,1  ,DS,3* 

UTC, 137, 11. 0,2.0, 1.0, (12)1.0* 

HOD, 137,1 ,D,T* 

BET, 137, 40* 

• 

*  OPERATOR  TASK  12,  SELECT  LAUNCHER  (FCO) 

• 

TAS,12,0BSVINCH,1,1,DS,I* 

UTC, 12, 12. 0,1. 0,1.0* 

BET, 12, 138* 
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• 

TAS,138,ENDTS12,1,1,BS,1* 

UTC, 138,12.0,2.0,1.0, <12)1.0* 

CAL, 138,  40,AEV,0,1*.,IA,, 

143,AEV,1 .0,1 1 ,IA* 

• 

•  OPERATOP  TASK  13,  FIRE  MISSILES  (FCO) 

• 

TAS,13,BECFCTyF,1,1 ,BS,1* 

UTC, 13, 13. 0,1. 0,1.0* 

CFI,13,143,AEV, 1 .0,13,IA,,139,AEV,2.0,13,IA* 

* 

TAS,1 43,PSHFBSLS,1 ,1 ,BS,1* 

UTC, 143, 13. 0,0. 0,1.0* 

iAL,143,1 42,UHC,,,, ,'3A,AGV,0.0,14,IA* 

* 

TAS,137,PSHFBRP1 ,1 ,1 ,DS,1* 

UTC, 137, 13. 0,0. 0,1.0* 

CAL,139,140,AEV,0.0,14,XA,, 

12,AEV,1.0,14,IA,, 

142,AEV,2.0,14, IA, , 

1 34, AW, 0.0, 14, IA* 

TAS,140,UAITRPFR,1, 1 ,US, 1* 

UTC, 140, 13. 0,0. 0,1.0* 

BET, 140,1 43* 

• 

TAS,142,ENBTSK13,1,1,DS,3* 

UTC, 142, 13. 0,2. 0,1.0* 

HOD, 142,1 ,D,T* 

BET, 142, 40* 

•  «- 

«  OPERATOR  TASK  14,  EVALUATE  TARGET  INTERCEPT  (FCO) 

• 

TAS, 1 4,UAITINTP,1 , 1 ,UF, 1  * 

!iTC, 14, 14. 0,1. 0,1.0* 

H0B,14,1 ,B,T* 

BET, 14, 144* 

• 

TAS,144,AUBTNIST,1,1,BS,1* 

UTC, 144, 14. 0,0. 0,1.0* 

BET, 144, 145* 

• 

TAS,145,DR0PD0P,t,1,BS,l* 

UTC, 143, 14. 0,0. 0,1.0* 

CFI,145,148,AEV,1 . 0,1 4, 1  A, ,146, AEV, 0.0, 14,1  A* 
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TAS,148,PRSKILLB,1,1,DS,1* 

UTC, 148, 14. 0,0. 0,1.0* 

DET, 148,149* 

• 

TA5,144,GVERBNK,1 ,1 ,DS,1* 

UTC, 144, 14. 0,0. 0,1.0* 

CFI,144, 1 47, AEV, 1 .0, 1S,IA, ,101 ,AEV,2.C,  14,  IA* 

• 

T  AS ,101 ,UAITHSGK,1 , 1 ,0S,4* 

UTC, 101, 14. 0,0. 0,1.0* 

X0D,101 ,1 ,B,T^ 

•  NO  IRANCK,  MUST  SE  CLEARED  TO  TASK  147  OR  TASK  150 

* 

TAS,14?,PRSN0KLL, 1 ,1 ,BS, 1* 

UTC, 147, 14. 0,0. 0,1.0* 

DET, 147, 14?* 

• 

TAS, 150, SHOOTER, 1,1,25,1* 

UTC, ISO, 14. 0,0. 0,1.0* 

HOB ,150,1 ,D,T* 

DET, 150, 140* 

• 

TAS,149lPRSBRKU,1,1,DS,1* 

UTC, 149, 14. 0,0. 0,1.0* 

DET, 149, 140* 

* 

TAS, 140, ENDTSK  14,1 ,1 ,DS,3* 

UTC, 140, 14. 0,2. 0,1.0, (12)1.0* 
flOD, 140,1 ,D,T* 

DET, 140, 40* 

* 

*  OPERATOR  TASK  IS,  PUT  FIRE  SECTION  BACK  IN  ACTION 

• 

TAS,  15,  PSHFSACT,  1,1, 1)3,1* 

UTC, 15, 15. 0,3. 0,1.0* 

HOD, 15, 1 ,D,T* 

DET, 15, 40* 

* 

•  OPERATOR  TASK  14,  PROCESS  CHANGE  TARGETS  COMMAND  < FCO » 

• 

TAS,14,PRCHTRGT,1,1,DS,1* 

UTC, 14, 14. 0,1. 0,1.0* 

DET, 14, 161* 

• 

TAS, 161 ,PSHBREAK,1 , 1 ,DS,  1* 

UTC, 161, 14. 0,2. 0,1. 0,112)1.0* 

DET, 161, 40* 
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•  OPERATOR  TASK  17,  TCA  MONITOR  CRT, CONTOLS, INDICATORS 

* 

TAS,17,TCASTNDB,1,1 ,DS, 1* 

UTC, 17, 17. 0,3. 0,1.0* 

BET, 17, 40* 

* 

•  OPERATOR  TASK  18,  ACCEPT  CUTDC  TARGET  FROM  ASO  (TCA) 

• 

TAS,1B,PCCHANDU,1,t,DS,1* 

UTC, 18, 18. 0,1. 0,1.0* 

BET, 18, 162* 

• 

TAS,162,PRCUC0NF,1 , 1 , OS ,  1  * 

UTC, 162,18. 0,0. 0,1.0* 

BET,  182, 163* 

* 

TAS, 1 63,C0RLTGT, 1  1,BS,1« 

L*TC,  163, 18. 0,2.0,  JO, (12)1.0* 

BET, 163, 40*  ! 

♦  . 

•  OPERATOR  TASK  1?,  IFF  CHALLENGE  (TCA)  ! 

•  I 
TAS,19,SLTIFFH,t,1 , DS , 1  * 

UTC, 19, 19. 0,1. 0,1.0* 

BET, 19, 164* 

• 

TAS,164,UAITSUEP,1 ,1 ,BS,1* 

UTC, 164, 19. 0,0. 0,1.0* 

BET, 164, 165* 

TAS,165,M0MTIFFN,1 *1 ,DS,1* 

UTC, 165, 19. 0,2. 0,1.0, (12)1.0* 

BET, 165,40*  j 

•  OPERATOR  TASK  20,  MARK  ON  REFLECTION  PLOTTER  (TCA) 

•  | 

TAS,20,BCDATDLS,1,i,BS,1* 

UTC, 20, 20. 0,1. 0,1.0* 

CFI,20,166,AEV,1.0,13,IA,,167,AEV,2.0,13,1»* 

• 

TAS, 1 66,HRKRFLCT,1 , 1 ,BS, 1  * 

UTC, 166, 20. 0,0. 0,1.0* 

BET, 166, 167* 

* 

TAS,167,ENDTSK20,1 ,1 ,BS,3* 

UTC, 167, 20. 0,2. 0,1.0, (12)1.0* 

MOO, 167,1 ,D,T*  I 

BET, 167, 40* 
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*  OPERATOR  TASK  21,  TCO  MONITOR  CRT, CONTROLS, INDICATORS 

• 

TAS,21 ,TCOSTNDB, 1 , 1 ,DS,1* 

UTC, 21, 21. 0,3. 0,1.0* 

DEI, 21 ,40* 

* 

•  OPERATOR  TASK  22,  DETECT  AN  ASSIGN  IPAR  ADP  TARGET  (TCO) 

• 

TAS,22,DTCTIPAR,1 ,1 ,DS,1* 

OTC, 22, 22. 0,1. 0,1.0* 

DET, 22,168* 

* 

TAS,168,IFFBATT,1,1,DS,1* 

UTC, 168, 22. 0,0. 0,1.0* 

CFI,168,169,AEV,2.0,13,IA, ,170,UNC* 

* 

TAS,169,ENDTSK22,1 ,1 ,D3,3* 

UTC, 16?, 22. 0,2. 0,1. 0,<12) 1.0* 

M0D,169,t,D,T* 

DET, 169,40* 

• 

TAS,170,PRFLASH,1,1,DS,1* 

UTC, 170, 22. 0,0. 0,1.0* 

DET, 170, 169* 

« 

•  OPERATOR  TASK  23,  MANUALLY  ASSIGN  TARGET(TCO) 

• 

TAS,23,EVALTHRT,1,1,DS,1* 

UTC, 23, 23. 0,1. 0,1.0* 

DET, 23, 178* 

• 

TAS,178,OIFFHON,1 ,1 ,DSf 1* 

UTC, 178, 23. 0,0. 0,1.0* 

DET, 178, 179* 

* 

TAS,179,DECATDLD, 1 , 1 ,DS,1* 

UTC, 179, 23. 0,0. 0,1.0* 

CF1,179,180,AEV,1 .0,1 3,1 A, ,18B,AEV,2.0,13,1A* 

* 

TAS,18B,PLTS0VAS, 1 ,1 ,DS,1* 

UTC, 188, 23. 0,0. 0,1.0* 

DET, 188, 189* 

« 

TAS,189,PREN0TH,t ,t , OS , I  * 

UTC, 189, 23. 0,0. 0,1.0* 

DET, 189, 190* 
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TAS,190,08SLBLS,1,1,DS,1* 

UTC, 190, 23. 0,0. 0,1.0* 

BET, 190,187* 

• 

TAS,180,DETL0C,1 ,1 ,DS,1* 

UTC, 180, 23. 0,0. 0,1.0* 

BET, 180, 181* 

t 

TAS, 1 81 ,PTS0VPPI,1 ,1 ,BS,1* 

UTC, 181, 23. 0,0. 0,1.0* 

BET, 181, 182* 

* 

TAS,182,PALAB,1 ,1 ,DS,1* 

UTC, 182, 23. 0,0. 0,1.0* 

BET, 182, 187* 

• 

TAS,187,ENDTSK23,1 ,1  ,1)S,3* 

UTC, 187, 23. 0,2. 0,1. 0,112)1.0* 

HOD, 187,1, D, T* 

DET , 1 87 ,40* 

* 

*  OPERATOR  TASK  24,  IHIPIR  TRACKING  1TC0) 

* 

TAS,24,EVALHDAT,1 ,1 , 05 , 1  * 

I'TC,  24, 24. 0,1. 0,1.0* 

DET, 24, 194* 

• 

TAS,194,FC0ESTS,  1 ,1 ,  DS,  1  * 

UTC, 194, 24. 0,0. 0,1.0* 

DET, 194, 195* 

• 

TAS,195,0IFFTC, 1 , 1  ,DS,1 * 

UTC, 195, 24. 0,2. 0,1. 0,112)1.0* 

BET, 195, 40* 

• 

♦  OPERATOR  TASK  25,  SEND  CANNOT  COMPLY  MESSAGE  TO  0-73  1TC0) 

* 

TAS,25,SN3CC0HP,1,t , DS, 1* 

UTC, 25, 25. 0,3. 0,1.0* 

DET, 25, 40* 

• 

*  OPERATOR  TASK  24,  HIGHER  PRIORITY  TARGET  TO  BE  ASSIGNED  TO  FS  1TC0) 

• 

TAS,26,HIGHPRI ,1,1 , OS , 1  * 

UTC, 26, 26. 0,1. 0,1.0* 

DET, 26, 60* 
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TAE, &0,PRHLDCT, 1 ,  1  ,DS, 1* 

UTC, 60,26.0,0.0, 1 .0* 

DEI, 60, 61* 

* 

TAS,61 ,£NElTSK26, 1 ,  1 ,DS,3* 

UTC, 61 ,26.0,2.0,1 .0,(1 2)1 .0* 

HOD, 61 ,1  ,D,T* 

DET ,61 ,40* 

* 

♦  OPERATOR  TASK  27,  PROCESS  HOSTILE  TARGET  (TCO) 

• 

TAS,27,SETRFCFR,1 ,1,05,14 
UTC, 27, 27. 0,1. 0,1.0* 

DET, 27, 62* 

• 

TAS,62,DCBFIRET,1 ,1 ,DS, 1* 

UTC, 62, 27. 0,0. 0,1.0* 

DET, 62, 63* 

• 

TAS,63, ISSFIREC, 1 ,1,BS,t* 

UTC, 63, 27. 0,0. 0,1.0* 

DET, 63, 64* 

* 

TAS,64, ENDTSK27, 1 , 1 ,DS,3* 

UTC, 64, 27. 0,2. 0,1  .0, <12)1.0* 

HOD, 64,1 ,D,T* 

DET, 64. 40* 

t 

*  OPERATOR  TASK  28, ASSIGNED  TARGET  DETERHINED  FRIEND  (TCO) 

* 

TAS,28,PRSSCHT, 1 ,1 ,DS,1* 

UTC, 28, 28. 0,3. 0,1  .0* 

DET, 28, 40* 

* 

»  OPERATOR  TASK  29,  PROCESS  FRIEND  (TCO) 

« 

TAS,29,DCAADCPF,1,!,DS,1* 

UTC, 29, 29. 0,1. 0,1.0* 

CFI,29,71,AEV,2.0,13,IA,,69,AEV,1.0,13,IA* 

• 

TAS,69,PLTRCKST,1 ,1 ,0S,1* 

UTC, 69, 29. 0,0. 0,1.0* 

DET, 69, 70* 

• 

TAS,70,PRSSFSU,1,1,DS,1* 

UTC, 70, 29. 0,0. 0,1.0* 

DET, 70, 72* 


X-290 


Jr-  y-jr- 

'•  t >V% 


■ 


TAS,71,STRFSU,1,1 ,DS,1* 

UTC, 71, 29. 0,0. 0,1.0* 

DET, 71, 72* 

* 

TAS,72,ENDTSK29,1 ,1 ,DS,3* 

UTC, 72, 29.0,:. 0,1.0, (12)1.0* 

MOD, 72,1 ,D,T* 

BET, 72, 40* 

* 

*  OPERATOR  TASK  30,  EVALUATE  MORE  MISSILES  OCD) 

* 

TAS,30,T0GRCCF,1,1,BS,1* 

UTC, 30, 30. 0,1. 0,1. 05 
DET,30,73* 

• 

TAS,73,BYDEFER,1 ,1  ,DS,1* 

UTC, 73, 30. 0,0. 0,1.0* 

CFI,73,74,AEV,1.0,13,IA,,75,AEV,2.0,13,IA* 

* 

TAS,74,0N0KILL,1,t,DS,1* 

UTC, 74, 30. 0,0. 0,1.0* 

D£T,74,75* 

• 

TAS,75,ENDTSK30,1,1,DS,3* 

UTC, 73, 30. 0,2. 0,1.0* 

MOD, 73,1 ,D,T* 

DET, 75,40* 

* 

*  OPERATOR  TASK  31,  GIVE  ASO  PERMISSION  TO  CANCEL  ALERT  <TCO) 

• 

TAS,31 ,PERHCNCL,1 ,1 , DS , 1  * 

UTC, 31, 31. 0,3. 0,1.0* 

DET, 31, 40* 

* 

»  OPERATOR  TASK  32,  TCO  RECEIVE  MESSAGES 

* 

TA  ',32,TC0RM5G,1 ,1 ,GS, 1  * 

U1C,  32, 32. 0,1. 0,1.0* 

HOD, 32,1 ,D,T* 

CFI ,22,77,ALV,3.0,13,1A, , 

78,  AGV,5.0, 1 3, IA, , 

79, AEV,3.0,13,IA,, 

81 ,AEV,4.0,13,IA* 

* 

TAS,7?,RECQ73M,1,1,DS,1* 

UTC, 77, 32. 0,0. 0,1.0*  , 

MOD, 77, 1 ,D,T* 

DET, 77, 80* 
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* 

k. 

TAS,153,DCDMSSEN,1,1,US,1* 

& 

a 

UTC, 153,37. 0,0. 0,1.0* 

CFI, 153, 154, AEV, 1.0, 15, IA,, 155, AEV, 2.0f  15 

• 

•r. 

TAS,154,0FC0BLCK,1 , 1  ,DS,1* 

UTC, 154, 37. 0,0.0, 1.0* 

A 

DEI, 154, 155* 

£ 

• 

TAS,155,ENDTSK37,1 ,1 ,DS,3* 

««r 

UTC. 155, 37. 0,2. 0,1.0, (12)1.0* 

V. 

HOD, 155,1,0,1* 

■' 

DET , 1 55 , 40» 

• 

* 

•  OPERATOR  TASK  40,  TASK  SEQUENCING 

* 

•  * 

TAS,40,TASKSEQU, 1 ,1 ,DS,1* 

UTC, 40, 40. 0,1. 0,1.0* 

H0D,40,1 ,D,T* 

CF 1 ,40,91 ,AEV,3.0,3, IA, , 

92, AEV,5.0,3,IA,, 

93,  AEV, 4.0, 3, IA,, 

94,AGV,5.0,3,IA* 

h  - 

0 

TAS,?1 ,TC0TSEQ, 1 , 1 ,DS,1* 

i  •' 

UTC, 91, 40. 0,0. 0,1.0* 

HOD, 91 ,1 ,D,T* 

fee’* 

CF 1,91 ,95, ALV, 27. 0,1 4, I A,, 

©• 

90, ALU, 32.0, 14, IA,, 

97, ALV, 38.0, 14, IA* 

* 

¥ 

TAS,95,TC0R0UT1 ,1 , 1 ,DS,1* 

UTC, 95, 40. 0,2. 0,1.0* 

HOD, 95,1 ,D,T* 

CFI,9S,21 ,AEV,21 .0,1 4, 1  A,, 

c,; 

22,  AEV, 22. 0,1 4, I A,, 

23,  AEV, 23. 0,1 4, I A,, 

' 

24, AEV, 24.0, 14, IA,, 

26, AEV, 24.0, 14, IA* 

• 

TAS,96,TC0R0UT2,1 ,1  ,BS,1* 

UTC, 94, 40. 0,2. 0,1.0* 

»■  ~ 

HOD, 96,1 , D , T  * 

CF 1, 96, 27, AEV, 27.0, 14,1  A, , 

»  • 

28, AEV, 28.0, 14, IA,, 

Ir 

29,  AEV, 29.0, 14, IA,, 

30, AEV,30.0,I«,IA,, 

* % 

31, AEV, 31.0, 14, IA* 

i  * 

i 

, 
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TAS,97,  iCI)R0UT3,1 , 1  ,DS,1* 

UTC, 97, 40  0,2. 0,1.0* 

HOD, 97,1 ,D,T* 

CF  1, 97, 32, AEV, 32.0, I*3, IA,, 

3CLAEV,35.0  i4,JA,, 

3?LAEV,37.0,U,IA* 

*  | 

TAS,92,AS0TSEQ,1 ,1  ,US,1* 

UTC, 92,40. 0,2.0, 1.0* 

H0B,92,1,0,T* 

CFIf?2,l,{tFV,1.0,14,IA,f 

2, AEV,2.0, *4,IA, , 

3,  AEV, 3. 0,14,14,, 

4,  AEV, 4.0, 14, IA, , 

5,  AEV, 5.0, 14, IA,, 

A, AEV, 4.0, 14, IA* 

♦  i 

TAS,93, TCATSEQ,  1 , 1 ,DS,1» 

UTC, 93,40. 0,2. 0,1.0* 

“90,93, I ,D,T* 

CFI,93,17,AEV,17.0,14,IA,, 

18,  AEV, 18.0, 14, IA,, 

19, AEV,19.0,)4,IA,, 

20,  AEV, 20.0, 14, IA* 

• 

TAS,94,FC0TSEQ,  1 , 1 ,BS, 1  * 

UTC, 94, 40. 0,2. 0,1.0* 

«0D,94,1,D,r» 

CFI,94,99,Al  7, 13.0, 14, IA, , 100, AG V, 12.0. t «, IA* 

* 

TAS,99,FC0R0UT1 ,  1 , 1  ,DS  - 1  • 

UTC, 99, 40. 0,2. 0,1.0* 

HOD, 99, 1 , D,T* 

CFI.99,  7, AEV,  7.0,14,IA,, 

8,  AEV,  8.0, 1 4, IA, , 

9,  AEV,  9.0, 1 4, IA, , 

10,  AEV, 10.0, 14, IA,, 

11,  AEV, 11.0, 14, JA,, 

12,  AEV, 12.0, 14, IA* 

• 

TAS,1O0,FCOR0UT2,1 , 1  ,DS,1* 

UTC, 100, 40. 0,2. 0,1.0* 

HOD, 100, 1,0, T* 

CF  1, 100, 13, AEV, 13.0, 14, IA,, 

14,  AEV, 14.0, 14, IA,, 

15,  AEV, 15.0, 14, IA,, 

14, AEV, 14.0, 14, IA* 
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MOPADS  Terminology 


AIR  DEFENSE  SYSTEM 

A  component  of  Air  Defense  which  includes 
equipment  and  operators  and  for  which 
technical  and  tactical  training  arerequired. 
Examples  are  IHAWK  end  the  AN/TSQ-T3. 

AIR  DEFENSE  SYSTEM 
MODULE  (ADSM) 

Models  of  operator  actions  and  equipment 
characteristics  for  Air  Defense  Systems  in 
the  MOPADS  software.  These  models  are  pre¬ 
pared  with  the  SAINT  simulation  language. 

Air  Defense  System  Modules  include  the 

SAINT  model  and  all  data  needed  to  com¬ 
pletely  define  task  element  times,  task 
sequencing  requirements,  and  human  factors 
influences. 

AIR  SCENARIO 

A  spatial  and  temporal  record  of  aerial 
activities  and  characteristics  of  an  air 
defense  battle.  The  Air  Scenario  includes 
aircraft  tracks,  safe  corridors,  ECM,  and 
other  aircraft  and  airspace  data.  See 
also  Tactical  Scenario. 

BRANCHING 

A  term  used  in  the  SAINT  simulation  lang¬ 
uage  to  mean  the  process  by  which  TASK  nodes 
are  sequenced.  At  the  completion  of  the 
simulated  activity  at  a  TASK  node,  the 
Branching  from  that  node  determines  which 
TASK  nodes  will  be  simulated  next. 

DATA  BASE  CONTROL 
SYSTEM 

That  part  of  the  MOPADS  software  which 
performs  all  direct  communication  with  the 
MOPADS  Data  Base.  All  information  transfer 
to  and  from  the  data  base  is  performed  by 
invoking  the  subprograms  which  make  up  the 
Data  Base  Control  System. 

DATA  SOURCE 

SPECIALIST 

A  specialist  in  obtaining  and  interpreting 
Army  documentation  and  other  data  needed  to 
prepare  Air  Defense  System  Modules. 
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ENVIRONMENTAL 

STATE  VARIABLE 

An  element  of  an  Environmental  State 

Vector. 

ENVIRONMENTAL 

STATE  VECTOR 

An  array  of  values  representing  conditions 
or  characteristics  that  may  affect  more 
than  one  operator.  Elements  of  Environmen¬ 
tal  State  Vectors  may  change  dynamically 
during  a  MOPADS  simulation  to  represent 
changes  in  the  environment  conditions. 

‘moderator  FUNCTION 

A  mathematical/logical  relationship  which 
alters  the  nominal  time  to  perform  an  opera¬ 
tor  activity  (usually  a  Task  Element).  The 
nominal  time  iB  changed  to  represent  the 
operator's  capability  to  perform  the 
activity  based  on  the  Operator’s  State 
Vector. 

MOPADS  DATA  BASE 

A  computerized  data  base  designed  specifi¬ 
cally  to  support  the  MOPADS  software.  The 
MOPADS  Data  Base  contains  Simulation  Data 
Set(s).  It  communicates  interactively  with 
MOPADS  Users  during  pre-  and  post-run  data 
specification  and  dynamically  with  the  SAINT 
software  during  simulation. 

MOPADS  MODELER 

An  analyst  who  will  develop  Air  Defense 
System  Modules  and  modify/ develop  the 

MOPADS  software  system. 

MOPADS  USER 

An  analyst  who  will  design  and  conduct  simu¬ 
lation  experiments  with  the  MOPADS  software. 

MSAINT 

(MOPADS/SAINT) 

The  variant  of  SAINT  used  in  the  MOPADS 
system.  The  standard  version  of  SAINT  has 
been  modified  for  MOPADS  to  permit  share¬ 
able  subnetworks  and  more  sophisticated 
interrupts.  The  terms  SAINT  and  MSAINT  are 
used  interchangeably  when  no  confusion  will 
result.  See  also,  SAINT. 
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OPERATOR  STATE  One  element  of  an  Operator  State  Vector. 

VARIABLE 


OPERATOR  STATE  An  array  of  values  representing  the  condi- 

VECTOR  tion  and  characteristics  of  an  operator  of 

an  Air  Defense  System.  Many  values  of  the 
Operator  State  Vector  will  change  dynamically 
during  the  course  of  a  MOPADS  simulation  to 
represent  changes  in  operator  condition. 


OPERATOR  TASK  An  operator  activity  identified  during 

weapons  system  front-end  analyses. 


SAINT  The  underlying  computer  simulation  language 

used  to  model  Air  Defense  Systems  in  Air 
Defense  System  Modules.  SAINT  is  an  acronym 
for  Systems  Analysis  of  Integrated  Networks 
of  Tasks.  It  is  a  well  documented  language 
designed  specifically  to  represent  human 
factors  aspects  of  man/machine  systems. 

See  also  MSAINT. 


SIMULATION  DATA  SET  The  Tactical  Scenario  plus  all  required 

simulation  initialization  and  other  experi¬ 
mental  data  needed  to  perform  a  MOPADS 
simulation. 


SIMULATION  STATE  At  any  instant  in  time  of  a  MOPADS  simula¬ 

tion  the  Simulation  State  is  the  set  of 
values  of  all  variables  in  the  MOPADS  soft¬ 
ware  and  the  MOPADS  Data  Base. 


SYSTEM  MODULES  See  Air  Defense  System  Modules. 


TACTICAL  SCENARIO  The  Air  Scenario  plus  specificati in  of 

critical  assets  and  the  air  -defense  con¬ 
figuration  (number,  type  and  location  of 
weapons  and  the  command  and  control  system) . 
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TACTICAL  SCENARIO 
COMPONENT 

An  element  of  a  Tactical  Scenario,  e.g. , 
if  a  Tactical  Scenario  contains  several 
Q-73's,  each  one  is  a  Tactical  Scenario 
Component . 

TASK 

See  Operator  Task. 

TASK  ELEMENTS 

Individual  operator  actions  which,  when 
grouped  appropriately,  make  up  operator 
tasks.  Task  elements  are  usually  repre¬ 
sented  by  single  SAINT  TASK  nodes  in  Air 
Defense  System  Modules. 

TASK  NODE 

A  modeling  symbol  used  in  the  SAINT  simula¬ 
tion  language.  A  TASK  node  represents  an 
activity;  depending  upon  the  modeling  cir¬ 
cumstances,  a  TASK  node  may  represent  an 
individual  activity  such  as  a  Task  Element, 
or  it  may  represent  an  aggregated  activity 
such  as  an  entire  Operator  Task. 

TASK  SEQUENCING 
MODERATOR 

FUNCTION 

A  mathematical/logical  relationship  which 
selects  the  next  Operator  Task  which  an 
operator  will  perform.  The  selection  is 
based  upon  operator  goal  seeking  character¬ 
istics. 

Additional  Terminology  and  Abbreviations 

ACN 

ADSM  Component  Number. 

ADSM 

Air  Defense  System  Module 

Reference  System 
Module 

A  code  11  directory  in  a  MOPADS  data  base 
which  contains  default  values  for  operator 
and  system  parrmeters.  It  is  the  "baseline" 
model  for  an  air  defense  system. 

DB 

Data  base. 

ID 

An  identifier.  ID’s  of  MOPADS  data  base 
entries  are  lists  of  integer  numbers. 

ACC 

ADSM  character  code.  A  single  character 
value  uniquely  assigned  to  a  reference 
system  module. 

DLCC 

Data  List  Character  Code.  A  one,  two,  or 
three  character  mnemonic  assigned  to  cer¬ 
tain  types  of  data  lists.  For  example, 
operator  state  vectors  have  a  DLCC  of  "OP.” 

NECC 

Number  Equivalent  of  a  Character  Code.  An 
integer  number  that  corresponds  to  a  short 
character  string.  The  capital  letters, 

A-Z,  correspond  to  the  integers  1-26  and 
the  digits  0-9  correspond  to  the  numbers 
27-36.  Thus  the  string  P2B  has  an  NECC  of 
162902  ("P"  corresponds  to  16,  "2"  to  29, 
and  "B"  to  02). 

DL 

Data  List.  A  list  of  values. 

DR 

Directors .  An  index  of  other  directories 
and/or  data  lists. 

/ 


I.  INTRODUCTION 


This  document  describes  the  particular  data  base  created  and 
used  by  the  MOPADS  software.  MOPADS  data  base  software  is  des¬ 
cribed  in  Polito  (1983a).  Here  we  ere  concerned  with  the  structure 
and  contents  of  the  data  base  file  used  to  implement  the  MOPADS 
simulations.  User  instructions  for  exercising  MOPADS  software  are 
contained  in  Polito  (1983b). 

The  MOPADS  data  base  contains  virtually  all  of  the  information 
required  to  set  up,  run,  and  review  MOPADS  simulations.  During 
initial  phases  of  development,  a  MOPADS  modeler  uses  the  User 
Interface  (Polito,  1983c)  to  create  reference  air  defense  system 
modules  and  air  scenarios  (Polito,  1983d, e).  This  information  is 
stored  in  the  MOPADS  data  base. 

With  the  above  building  blocks,  a  MOPADS  user  will  create  simu¬ 
lation  data  sets  that  contain  a  specific  command  and  control  struc¬ 
ture  involving  (perhaps)  multiple  copies  of  the  reference  system 
modules  and  specifying  a  particular  air-scenario.  When  this  simu¬ 
lation  data  set  is  executed,  the  resulting  statistics  are  stored  in 
the  data  base.  The  MOPADS  user  can  later  examine  thf>se  statistics 
and  select  those  he/she  desires  to  be  printed. 

The  data  base  may  contain  one  or  more  simulation  data  sets, 
so  multiple  analyses  can  be  performed  with  one  data  base  file.  Also, 
the  data  base  files  provide  ideal  vehicles  for  archiving  MOPADS  data, 
because  the  data  base  contains  all  of  the  required  data  to  duplicate 
a  simulation. 


II.  THE  MOPADS  DATA  BASE 


1-0  STRUCTURE  OF  THE  DATA  BASE. 

Figure  II-l  shows  the  structure  of  the  directories  in  the  IMOPADS 
data  base.  The  "DR"  in  the  boxes  indicates  a  directory  as  opposed 
to  a  data  list  (data  lists  are  not  shown  on  this  figure).  Directory 
labels  are  shown  in  capital  letters  in  the  larger  portions  of  |;he 
boxes.  If  the  label  section  has  an  entry  in  lower  case  letterB,  it  . 
indicates  that  an  arbitrary  number  of  these  directories  me./  exist 
with  user  assigned  labels.  The  numbers  over  the  upper  right  corners 
are  directory  codes  which  are  discussed  in  Section  2-0  below. 

1  , 

The  REFER EN CE-ADSM  directory  (code  2)  owns  all  reference  bystem 
modules.  The  reference  system  modules  are  copied  to  appropriate 
locations  in  a  particular  command  and  control  structure  where  they 
become  code  12  directories.  Multiple  copies  of  each  reference'  system 
module  may  be  copied  and  each  code  12  directory  may  be  edited  i 
individually.  j. 


Multiple  battlefield  scenarios  can  be  created.  They  are  all 
owned  by  the  SCENARIOS  directory  (code  U).  Multiple  CRITICAL-ASSET- 
CONFIGURATION  (code  13)  directories  can  be  created,  each  of  which 
may  contain  one  or  more  air  scenarios  (code  8). 


From  the  menu  of  reference-  system  modules  and  scenarios  avail¬ 
able,  the  user  may  construct  one  or  more  SIMULATION-DATA-SET 
(code  1)  directories  that  contain  all  information  necessary  to  per- 
fiom  MOPADS  simulations.  Each  offthe  directories  is  explained  in 
detail  in  Section  III. 

2- 0  DIRECTORY  CODES  AN?  CONTENTS . 

The  MOPADS  data  base  contains  lh  directory  types  identified 
by  directory  codes  numbered  from|  zero  to  13.  More  than  one  instance 
of  some  directory  types  may  exist  in  a  single  data  base.  Table  II-l 
explains  the  contents  of  each  directory  type. 

3- 0  IDENTIFIERS  AND  L/3EIS  FOR  CODE  11  AND  12  DIRECTORIES. 

Code  11  and  12  directories  have  systematic  conventions  for 
assigning  labels  and  ID's.  Labels  of  reference  ADSM's  (code  11) 
directories  consist  of  a  one-character  ADSM  code  character  ( ACL') 
followed  by  a  hyphen  (-)  and  a  text  string  of  up  to  23  characters. 
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Figure  XI-1.  Structure  of  MOPADS  Data  Base. 
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COHHAKB-AHfl-COHTROL  This  directory  owns  an  entire  connand  and  control  configuration. 

All  of  the  systen  nodules  in  the  configuration  descend  fron  this 
directory.  Each  code  (directory  contains  only  one  code  7 
directory. 
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Y-ll 


For  example: 


Q-BATTALI0N-Q-T3 

is  an  acceptable  reference  ADSM  label.  The  ACC  is  "Q".  Every 
reference  ADSM  must  have  a  unique  ACC.  The  ACC  is  used  in  develop¬ 
ing  mnemonic  labels  icr  system  modules  in  the  command  and  control 
configuration  as  will  be  seen  soon. 

Directory  identifiers  (DRID)  for  reference  ADSM’s  have  four 
▼allies  whose  definitions  are  shown  below. 


DRID(l) 

-  11 

DRID( 2) 

*  NECC(ACC) 

DRID( 3) 

*  0 

DFID(U) 

*  basic  ACN 

The  function  NECC  is  the  Number  Equivalent  of  Character  Code.  It 
converts,  in  this  case,  the  ACC  character  to  an  integer.  NECC  maps 
the  letters  A-Z  to  the  numbers  1-26  and  the  digits  0-9  to  the 
numbers  27-36. 

In  addition  to  the  ACC,  each  reference  ADSM  is  assigned  a 
basic  ADSM  Component  Number  (ACT?)  by  the  user.  The  basic  ACN  is  a 
multiple  of  1000  and  must  be  unique  for  the  ADSM.  When  reference 
ADSM's  are  copied  as  code  12  directories,  the  basic  ACN  is  incre¬ 
mented  to  identify  each  copy  (e.g.,  code  12  directories  might  have 
ACN's  of  1001,  1002,  1003,  etc.  for  a  reference  ADSM  with  a  basic 
ACN  of  1000). 

The  DR ID's  for  code  12  directories  are: 


DRID(l) 

=  12 

DR3D(2) 

=  NECC(ACC) 

DRID( 3) 

-  sequence  number 

DRID(U) 

=  ACN 

The  ACN  is  assigned  as  discussed  above  so  every  code  12  system 
module  directory  has  a  unique  value  in  its  fourth  ID  element.  The 
sequence  number  is  assigned  within  the  owning  directory.  For 
example,  suppose  there  are  two  battalion  Q-73's  each  with  three 
HAWK  batteries.  The  HAWK  batteries  for  each  Q-T3  will  be  numbered 
1,  2,  and  3  (their  sequence  numbers).  Thus  HAWKs  belonging  to  the 
different  Q-73’s  may  have  identical  values  for  DRID(3)  (but  of  : 
course  their  ACN's  will  be  different). 


*  / 


Labels  of  code  12  directories  reflect  their  location  in  the 


command  and  control  configuration.  This  i| 
ol  the  owning  directory  and  appending  the 


* 

w/ 


s  done  by  taking  the  label 
ACC  and  the  DRID(  3)  value 


to  it.  In  other  words,  the  ''component  suffix"  is  appended  to  the 
owning  directory's  label.  For  example. 


Q2H1+ 


might  be  the  label  of  the  fourth  HAWK  belonging  to  the  second  batta¬ 
lion  Q-73.  The  "U"  in  the  label  above  is  the  sequence  number  stored 
in  DRID(3)  of  the  HAWK  ID. 


The  labels  for  code  12  directories  are  assigned  automatically 
by  the  MOPADS  software  using  information  from  the  reference  ADSM's 
and  the  command  and  control  configuration. 


* 
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III.  CONTENTS  OF  THE  DIRECTORIES  AND  DATA  LISTS 


1-0  CONTENTS  OF  THIS  SECTION 

Section  III  contains  lists  of  the  information  contained  in 
each  directory  type  of  the  MOPADS  data  base.  Since  this  is  a 
reference  document,  no  extensive  definitions  or  discussion  of  the 
contents  are  provided.  Expanded  discussions  are  found  in  user 
documents  referred  to  in  Section  I.  Also,  it  is  assumed  that  the 
reader  is  familiar  with  the  concepts  in  Section  I  and  II  of  MOPADS 
Volume  5-13  (Polito,  1983a). 

The  function  NECC  is  used  in  several  instances.  NECC  can  trans¬ 
late  strings  greater  in  length  than  one  character  (which  was  the 
only  case  presented  in  Section  II,  3-0).  In  fact,  each  character  is 
mapped  to  a  two-digit  number  (which  may  have  a  leading  zero  if  the 
number  is  less  than  10)  and  these  two-digit  numbers  are  concatenated 
if  the  input  string  has  more  than  one  character.  As  examples. 


String  NECC( string) 


A  1 

BA  201 

ZZ  2626 

ZY  2625 

Note  that  NECC(  )  is  a  number,  not  a  string.  Therefore,  the  length 
of  the  input  string  that  can  be  converted  by  NECC  is  limited  by  the 
number  of  digits  which  the  computer  can  represent  as  an  integer 
number . 


Also,  some  data  list  labels  have  code  characters  that  identify 
them.  These  "Data  List  Code  Characters"  or  DLCC's  are  one,  two,  or 
three  characters.  A  data  list  label  with  a  DLCC  is  composed  of  the 
DLCC  followed  by  a  dash  (-)  followed  by  the  rest  of  the  label;  e.g., 
OP-OPERATOR-STATE- VECTOR.  Frequently,  the  ID  of  such  a  data  list 
contains  the  NECC  of  the  DLCC.  For  example,  NECC('OP')  is  1516. 

Each  subsequent  section  contains  a  description  of  a  directory. 

A  schematic  shows  the  directories  and  data  lists  owned  by  the  direc¬ 
tory, and  the  contents  of  all  owned  data  lists  is  given  in  detail. 
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1-1.  Forms  Used  in  This  Document. 

Three  forms  are  used  to  describe  the  contents  of  the 
KOPADS  data  base.  The  first  form  is  shovn  in  Figure  III-l.  Each 
directory  is  described  by  one  of  these  forms.  The  directory  code 
and  label  are  given  on  the  first  line.  The  directory  level  specified 
on  the  second  line  is  the  depth  of  the  directory  from  the  master 
directory.  For  example,  the  depth,  in  Figure  III-2  of  the  Code  2 
directory  ( REFERENCE- ADSM)  is  one  because  i+  is  owned  directly  by  the 
master  directory.  Similarly,  the  directory  level  of  Code  II  direc¬ 
tories  is  two. 

The  owner  directory  is  specified  next  in  Figure  III-l.  Next  is 
the  identifier  of  this  directory.  Recall  that  this  identifier  is 
stored  physically  in  the  directory  that  owns  this  diiectory.  Thus 
the  title  "ID  IN  OWNER  DIRECTORY." 

The  next  three  items  concern  the  ID's  of  directories  and  data 
lists  that  are  owned  by  this  directory.  First  the  number  of  words 
in  the  ID's  is  specified.  The  ranking  codes  for  owned  directories 
and  data  lists  is  given  next,  see  Folito  (1983a). 

The  second  form  shown  for  each  directory  is  the  Directory 
Contents  Form  shown  in  Figure  III-2.  All  owned  directories  and  data 
lists  are  shown  on  this  form.  In  the  "TYPE"  column  will  appear 
"DL"  or  "DR"  to  indicate  a  data  list  or  directory,  respectively.  For 
directories,  the  directory  code  will  be  specified  in  the  "CODE" 
column.  The  label  is  given  in  the  center  column,  and  the  number  of 
such  entities  which  may  be  owned  by  the  directory  will  be  given  in 
the  "NUMBER"  column.  This  column  will  be  either  "1"  to  indicate 
that  only  one  of  the  specified  data  list  or  directories  may  belong  to 
the  directory  or  "as  needed"  to  indicate  that  more  than  one  may  be 
owned.  For  example,  the  master  directory  may  own  more  than  one 
"SIMULATION-DATA-SET"  (Code  l)  directory.  It's  NUMBER  would  be 
specified  as  "as  needed"  in  the  directory  contents  form  of  the 
(MASTER  DIRECTORY). 

The  last  form  is  the  Data  List  Description  Form  shown  in 
Figure  III-3.  This  form  is  used  to  describe  the  detailed  contents 
of  all  data  lists.  As  discussed  in  Polito  (1983a),  each  data  list 
may  be  either  real  (RDL),  integer  (IDL),  or  character  (CDL).  RDL's 
and  IDL's  ray  be  two-dimensional,  and  all  elements  of  a  data  list 
may  have  a  25-character  label.  All  of  this  information  may  be  speci¬ 
fied  on  the  Data  List  Description  form. 

Space  exists  at  the  top  of  the  form  to  specify  the  data  list 
label,  the  owner  directory,  and  the  data  list  ID.  The  data  list 
type  is  also  specified.  For  example,  to  specify  a  two-dimensional, 
row-oriented,  real  data  list  whose  maximum  column  dimension  is  21, 
the  following  would  be  filled  in  on  the  form; 

X  RDL/0  C  DIM  =  21 

Y-I5 


3 

K-: 

f.s 
• , 


«2£ADS/data  |a§£  BIRfCiogr  descripiioh 

DIRECTORY  LABEL ( COSE/LABEL ) i _ 

DIRECTORY  LEVEL! _ _ _ 

OUNER  DIRECTORY(CQDE): _ 

ID  IN  OUNER  DIRECTORY!... _ 

NUMBER  OF  UORDS  IN  ID'S  OF 

OWNED  DIRECTORIES  l  DATA  LISTS! _ 

RANKING  CODE  FOR  OUNED  DIRECTORIES: _ 

RANKING  CODE  FOR  OUNED  DATA  LISTS: 


Hfil^S/DIRECTORT  CONTENTS 


Figure  III-2.  Directory  Contents  Form. 
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In  the  case  of  character  data  lists,  only  the  maximum  number  of 
characters  per  element  may  ce  specified. 

The  body  of  the  form  is  filled  in  to  describe  the  individual 
data  list  elements.  For  one-dimensional  data  lists,  the  elements 
are  numbered  in  the  left-hand  column,  and  the  label  and  element 
descriptions  are  given  in  the  indicated  columns.  If  initial  or 
default  values  are  specified  for  elements,  they  are  given  with  the 
following  notation:  "(I)2"  implies  an  initial  value  and  "(D)=" 
implies  a  default;  e.g. ,  (I)  =  16  and  (D)  =  21. k. 

For  two-dimensional  data  lists,  one  dimension  must  be  fixed. 

If  it  is  a  row-oriented  DL,  then  the  column  dimension  is  fixed.  In 
this  case,  each  column  generally  has  a  fixed  meaning,  and  as  many 
rows  as  needed  can  be  included.  The  column  definitions  are  specified 
by  putting  the  column  numbers  in  the  first  column  as  follows:  Cl, 

C2,  C3,  etc.  If  a  label  is  provided  for  that  column  (actually  in  row 
1  of  the  data  list),  it  is  put  in  the  label  column.  The  column 
definition  is  given  in  the  last  column  as  before.  For  column 
oriented  DL's,  the  situation  is  reversed,  and  row  definitions  are 
given  with  the  notation  Rl,  R2,  R3,  etc.  used  in  the  first  column 
of  the  form. 
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jJ£PADS/MRECI2BI  CS32EHI5 

MRECTORY  CODE: 

0 

1  titter* 

(MASTER-DIRECTORY) 

1 

1 

1 

1 

1 

1 

1 

1 

1 

s 

1 

• 

1 

j 

1 

TYPE 

CODE 

LABEL 

NUMBER 

DR 

1 

SIMULATION-DATA-SET 

as  needed 

DR 

2 

REFERENCE-ADSM 

1 

DR 

4 

SCENARIOS 

1 

DL 


DB-TITLE 


1 


3-0  THE  "SIMULATION-DATA-SET"  DIRECTORY  (CODE  l) 

BSE ads/daia  ba|I  SHEmBI  K5EBIEIIM 

DIRECTORY  LABEL! CODE/LABEL > i _ 1 j SIMULATION-DATA-SET 

BIRECTORY  LEVEL* _ }_ _ 

OWNER  DIRECTORY  (CODE): _ 0|  (MASTER- DIRECTORY) 

II  IN  OUNER  DIRECTORY: _ 1| (sequence  number) 

NUNBER  OF  UORDS  IN  ID'S  OF 

DUNE!  DIRECTORIES  1  DATA  LISTS* _ f _ 

RANKING  CODE  FOR  OUNED  DIRECTORIES* _ } _ 

RANKING  CODE  FOR  OUNED  DATA  LISTS* _ } _ 

DESCRIPTION* 


* 


(i 


U-0  THE  "REFEREN C E-ADSM"  DIRECTORY  (CODE  2) 


09£ADS/DAIA  BASF 
DIRECTORY  LABEL ( CODE/LABEL >  t 

DIRECTORY  LEVEL! _ 

OUHER  DIRECTORY(CODE)i _ 

ID  IN  OUHER  DIRECTORY!  _ 


CIRSEISBI  fi£SCRj£l20jf 
2 1 REFERENCE-ADSM 

1 

Q[ (MASTER-DIRECTORY) 
2|1 


NUMBER  OF  WORDS  IN  ID'S  OF  4 

OUNED  DIRECTORIES  t  DATA  LISTS! _ 

RANKING  CODE  FOR  OUNED  DIRECTORIES! _ f. 

RANKING  CODE  FOR  OUNED  DATA  LISTSi  2 


DESCRIPTION! 


IJOPABS/DIRECIOjRI  rOHTEHTS 

DIRECTORY  CODE* _ JL _ 

BIRECTORY  LABEL* _ REFERENCE- ADS M _ 

TYPE  CODE  LABEL 

DL  -  SKILL-CATEGORIES 

DR  11  reference  ADSM'S 


kVj\ 


c. 


-28 


5-0  THE  "RUN-n"  DIRECTORY  (CODE  3) 


HOPABS/DATA  BASJ  BHi£I98I  DESCRIPTION 

DIRECTORY  LABEL(C0BE/LABELi*^j3UN-n_ _ 

h 

DIRECTORY  LEVEL* _ 

5 | STATISTICS 


OWNER  DIRECTQRYCCODE) * _ _ 

II  IN  OWNER  DIRECTORY  *„.__ 


3|n 


NUMBER  OF  WORDS  IN  ID'S  OF 

OWNED  DIRECTORIES  1  DATA  LISTS* _ 2 _ 

RANKING  CODE  FOR  OWNED  DIRECTORIES* _ _ 

RANKING  CODE  FOR  OWNED  DATA  LISTS*  0 


DESCRIPTION* 


Y-2 9  ; 


HfliMsmimM  £OHims 

ilRECTORY  CQDEi_ _ ; 

DIRECTORY  LABEL i  _ f 


TYPE 


COPE 


LABEL 


DL 

DL 


TRACE 

STATISTICS-ARRAYS 


NUMBER 

1 

1 


NOPADS/DATA  BASE:  DATA  LIST  DESCRIPTION  5-17/DLD 


»‘.v 


v?v, 


6-0  THE  "SCENARIOS”  DIRECTORY  (CODE  k) 


d2£ACSZSM$  bas| 

DIRECTOR?  LABEL! COLE/LABEL): 

DIRECTORY  LEVEL: _ 

OUNER  DIRECTORY(CODE) : _ 

ID  IN  OUNER  DIRECTORY:.., _ 


8IS5CI8SI  DESCRIPTION 

...AlSCENARIOS.... _ 

_ 1 _ 

0 | (MASTER-DIRECTORY) 

4 1 0 


NUMBER  OF  UORDS  IN  ID'S  OF 

OUNED  DIRECTORIES  l  DATA  LISTS:.... 

RANKING  CODE  FOR  OUNED  DIRECTORIES: 

RANKING  CODE  FOR  OUNED  DATA  LISTS:. 

DESCRIPTION: 


fifl£*!§/fiiRi£ioRi  mum 


DIRECTORY  CODEt 


DIRECTORY  LABEL:  _ SCENARIOS 


TYPE 


CODE 


LABEL 


NUMBER 


DR 


13 


CRITICAL-ASSET-CONFIGURATION 


as  needed 


i 


7-0  T3E  "STATISTICS'’  DIRECTORY  (Code  5) 


IflSf 

DIRECTOR f  LABEL ( CQDE/LABEL > : 

Busciesi  fiiscRimss 

5 | STATISTICS 

DIRECTOR!  LEVEL:. 

3 

OWNER  DIRECTORY (CODE): 

6|TACTICAL  SCENARIO 

ID  IK  OWNER  DIRECTORY: 

5(1 

NUMBER  OF  UORDS  IN  ID'S  OF 

OUNED  DIRECTORIES  1  DATA  LISTS:  2 

RANKING  CODE  FOR  OWNED  DIRECTORIES:  2 

RANKING  CODE  FOR  CUNED  DATA 

LISTS:  0 

DESCRIPTION: 


r-35 


HOPADS/PIRCCIOHr  EfiiillWIS 
DIRECTORY  COBtt _ L 


DIRECTORY  LABEL: _ STAT JSS3S&. 


TYPE 

CODE 

LABEL 

NUMBER 

DR 

3 

RUN-n 

multiple 

DL 

- 

MSAIHT-DATA 

1 

DL 

LABELS 

1 

Y-40 


8-0  THE  "TACTICAL  SCENARIO"  DIRECTORY  (CODE  6) 


«gpAD§miA  |A|5 
DIRECTORY  LABEL (CODE/LABEL ) : 

DIRECTORY  LEVELi _ 

DUNER  DIRECTORY (''ODE): _ 

II  IN  OUNER  DIRECTORY: 


filRSCIfiSI  fiESCRIPIIOH 
6 (TACTICAL-SCENARIO 

2 

1-SI MUL AT I ON- DATA-S  ET 

S | (sequence  number)^ 


NUMBER  OF  UORDS  IN  ID'S  OF 

OUNED  DIRECTORIES  1  DATA  LISTS: _ 

RANKINS  CODE  FOR  OUNED  DIRECTORIES: 

RANKINS  CODE  FOR  OUNED  DATA  LISTS:. 

DESCRIPTION: 


NOPADS/ DATA  BASE:  DATA  LIST  DESCRIPTION  5-17/DLD 
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9-0  THE  "COMMAND-AND- CONTROL"  DIRECTORY  (CODE  7) 

dSESSSZSfilfi  |A£|  815SEISEI  SliCBIEIIoij 

DIRECTORY  LABEL  (CODE/LABEL) » _ 

DIRECTORY  LEVEL: _ 2 _ 

OUNER  DIRECTORY  (CODE) : _ 1|  SIMULATION-DATA-SET 

ID  IN  OUNER  DIRECTORY:  _ _7[l _ 

NUMBER  OF  UORDS  IN  ID'S  OF 

OUNED  DIRECTORIES  l  DATA  LISTS: _ .4 _ 

RANKING  CODE  FOR  OUNED  DIRECTORIES: _ _4 _ _ _ 

RANKING  CODE  FOR  GUNED  DATA  LISTS:  2 


DESCRIPTION: 


10-0  THE  AIR  SCENARIO  DIRECTORY  (CODE  8) 


dS^DS/DATA  BASS  BI8££I98I  SISCRIfliSH 

DIRECTORY  LABEL  (CODE/LABEL): _ 8juser  Specified  (AIR  SCENARIO) 

DIRECTORY  LEVEL! _ 3 _ 

OUHER  DIRECTORY(COLE): _ 13| CRITICAL -ASSET-CONFIGURATION 

ID  IN  OUNER  DIRECTORY:  _ uj_er_a_ssigned_nurnjD_ej^ _ 

NUMBER  OF  UORDS  IN  ID'S  OF  , 

OWNED  DIRECTORIES  2  DATA  LISTS! _ _ _ 

RANKING  CODE  FOR  OUNED  DIRECTORIES: _ _ _ 

RANKING  CODE  FOR  OUNED  DATA  LISTS! _ \ _ 

DESCRIPTION: 


Y-49 


not  us«d 


-0  THE  "MESSAGES"  DIRECTORY  (CODE  9) 


QOPASS/fiATA  IASS  BIR5EI25I  USEB1EI1M 

DIRECTORY  LABEttCQDE/LABEL J : _ _ 

BIRECTORY  LEVEL: _ _4_ _ 

OWNER  BIRECTORY  (CODE)  i _ 7  j  COWAN D-AND- CONTROL 

II  IN  OWNER  BIRECTORY  I _ f_L°J_0_L° _ 

NUMBER  OF  UOROS  IN  IB'S  OF 

OUNEB  DIRECTORIES  I  DATA  LISTS* _ 5_ _ 

RANKING  CODE  FOR  OWNED  DIRECTORIES: _ _0 _ 

RANKING  CODE  FOR  OWNED  BATA  LISTS: _ .0 _ 

DESCRIPTION: 


flJ2££15AtlSUl£J!l 

BIRECTCRY  COKEi _ 9 


IIRECTORT  LABEL! _ .^SAGES_ 
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SAINT  Task,  nods  nunbar  fiestas*  Is  seat  froa 


12-0  THE  "ACKNOWLEDGEMENT-MESSAGES "  DIRECTORY  (CODE  10 ) 


d2£A23/2*I*  1*55  51*££ISSI  2ISCRIPII2!! 

DIRECTORY  LABEL ( CODE/LABEL )  i _ 10  lACKNCWLJEJ^J^MO^^MESSAGES, 


DIRECTORY  LEVEL* _ Y!rj°_u_S-. 

OWNER  DIRECTORY  (CODE): _ 12 _ 

II  IN  OWNER  DIRECTORY! _ 10 1 1 1 0 1 ACN 

NUMBER  OF  WORDS  IN  ID'S  OF 

OLNEB  DIRECTORIES  1  DATA  LISTS! _ 5 _ 

RANKING  CODE  FOR  OWNED  DIRECTORIES! _ 0 


RANKING  CODE  FUR  OWNED  DATA  LISTS! _ 0 

DESCRIPTION! 


flflEafirHiBJEISSI  CfiJLtfSIS 


BIRECTORY  CODEt _ J.0 _ 

BIRECTORY  LABEL* _ ACKNOWLEDGEMENT-MESSAGES _ 

TYPE  I  CODE  |  LABEL  I  NUMBER 


DL 


ACK-MESSAGES-DL 


as  needed 


Y'57 


13-0  THE  REFERENCE  SYSTEM  MODULE  DIRECTORY  ( CODE  ll) 


S2ES2S/M*  IMS  MKSIfiBI  fiSICRiPiiOH 

DIRECTORY  LABEL (CODE/LABEL) t _ .11 L- _ 

BIRECTORY  LEVEL! _ A. _ _ 

OUNER  DIRECTORY (CODE) i _ _ 

IB  IN  OUNER  DIRECTORY : _ JjJilECC (_AC C ) J Oj b a_sijc__ACN _ 

NUMBER  OF  UORDS  IN  ID'S  OF 

OWNED  DIRECTORIES  1  DATA  LISTS* _ J* _ 

RANKING  CODE  FOR  OUNED  DIRECTORIES J..0 _ _ 

RANKING  CODE  FOR  OUNED  DATA  LISTS* _ 2 _ 

DESCRIPTION! 

*  The  label  is  a  one-character  ACC  followed  by  a  dash  (-) 
followed  by  a  user  specified  label;  e.g.,  Q-BATTALI0N-Q73. 


«S£^2S/SIRECT0RT  COHTEHTS 

DIRECTORY  CODE: _ 11 _ 

DIRECTORY  L AB EL : _ r__sj)_ec i_f i_ed 


HOPADS/DATA  BASE*  DAT.^  LIST  DESCRIPTION  5-17/DLD 
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5-17/DLB  -  0? 

TAR6ET  TYPE  COOES 


OE  NO. 

NAME 

COUNTRY 

MISSION 

1 

F4C 

USA 

2 

F100 

USA 

3 

T33 

USA 

4 

OTHER  JET 

USA 

S 

1)14 

USA 

4 

U4A 

USA 

7 

OTHER  PROP 

USA 

0 

014 

USA 

f 

OaJj 

USA 

10 

OTHER  HELICOPTER 

USA 

11 

T4NK 

USA 

12 

JEEP 

USA 

13 

TROOP 

USA 

14 

4PC 

USA 

13 

TRUCK 

USA 

14 

ZERO 

USA 

17 

HALFTRACK 

USA 

18 

F14 

USA 

If 

F13 

USA 

20 

F14 

USA 

21 

F18 

USA 

22 

(1162 1 

USA 

23 

HI623 

USA 

24 

HI023 

USA 

23 

SOLDIER(FQOT) 

ANT 

24 

HI6-27 

USSR 

27 

SU-17 

USSR 

2B 

0IAH0  Ji-5 

PRC 

Bround  Attack 

2f 

R-23S8 

FRANCE 

Military  survcillanct 

30 

HIRABE  3E 

FRANCE 

Fighter 

31 

HIRA6E  FI 

FRANCE 

Fighttr 

32 

HIRABE  2000 

FRANCE 

Fighter 

33 

HIRA6E  4000 

FRANCE 

Fighter 

34 

HIRABE  4 

FRANCE 

Bonber 

33 

HIRA6E  3 

FRANCE 

Ground  Support 

34 

HIRABE  39 

FRANCE 

Fighter 

37 

AU.440 

6REAT  iRITAIM 

Military  Transport 

38 

698 

6REAT  IRITAIM 

Bonber 

3f 

HS748 

BREAT  BRITAIN 

Military  Transport 

40 

HS.780 

RREAT  IRITAIN 

Military  Transport 

41 

P.1099 

BREAT  IRITAIN 

Bround  Attack 

FT-T TTOTV'.i 


42 

IA1202 

ISRAEL 

Military  Trsasoort 

43 

MIRAGE  JC 

ISRAEL 

Fightar 

44 

Kf irC2 

ISMAEL 

Fightar 

45 

6.222 

ITALY 

Military  Transport 

44 

F104S 

ITALY 

Interceptor 

47 

NB.324K 

ITALY 

Strtka 

48 

S.N.10I9E 

ITALY 

Hi.itary  STOL 

49 

F-1 

JAPAN 

Figitar 

SO 

C.207A 

SPAIN 

Military  Transport 

51 

SF-5A 

SPAIN 

Fightar 

52 

HA-220 

SPAIN 

Ground  Attack 

S3 

35X8 

SUEOEN 

6rcund  Attack 

54 

JA37 

SUE8EN 

Fightor 

55 

J-l 

YUGOSLAVIA 

Strika 

54 

Light  (a. g. blinking) 

57 

Digit  (digit  on  a 

display) 

58 

MI6-17 

USSR 

50 

MIG-19 

USSR 

40 

SU-7 

USSR 

41 

SU-9PM 

USSR 

42 

SU-11 

USS“ 

43 

SU-15 

USSR 

44 

SU-19 

USSR 

45 

SU-20 

USSR 

44 

YAK-28F 

us:r 

47 

YAK-34 

USSR 

48 

TU-28P 

USSR 

49 

IL-28 

USSR 

70 

M-4 

USSR 

71 

TU-14 

USSR 

72 

TU-20 

USSR 

73 

TU-22 

USSR 

74 

TU-24 

USSR 

75 

11-38 

USSR 

74 

TO— 1 26 

USSR 

t 

77 

MIG-15 

USSR 

78 

L-29 

USSR 

79 

L-39 

USSR 

80 

J-5 

USSR 

81 

J-4 

USSR 

82 

J-7 

USSR 

83 

J-8 

USSR 

84 

H-5 

USSR 

85 

H-4 

USSR 

84 

CJ-4 

USSR 

87 

Y-1 1 

USSR 

88 

MIRAGE  III 

FRANCE 

COLOR  COOES 


5-17/DLD  -  08 


Uhite 

Tan 

Green 

Hut 

Red 

Yellow 


ISSION  COOES 


6reund  attack 
Military  surveillance 
Fighter 
Botiber 

Oround  support 

Military  Transport 

Interceptor 

STOL 

Strike 


COUNTRY  COOES 


USA 

USSR 

PRC 

France 

Israel 


Italy 

Japan 

Spain 

Sweden 

Yugoslavia 
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1U0  THE  WORKING  SYSTEM  MODULE  DIRECTORY  (CODE  12) 


«$EB!§/SSI*  IASS  BHSClfiBI  B£S£BI!II88 

DIRECTORY  LAIEKCODE/LABEL) :  12 (determined  by  MOPADS* 


DIRECTORY  LEVEL t _ VARIOUS _ _ _ 

OWNER  DIRECTORY iCOBE) * _ 7  or  12  various _ 

II  IN  OWNER  DIRECTORY!  12 |NECC( ACC)  [sequence  numberjACN 


NUMBER  OF  WORDS  IN  ID'S  OF 
OWNED  DIRECTORIES  1  DATA  LISTS! 


RANKING  CODE  FOR  OWNED  DIRECTORIES! 


RANKING  CODE  FOR  OUhED  DATA  LISTS! 


DESCRIPTION! 

*  See  MOPADS  Volume  3.3 
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MZilS/HBSmBl  CQHIEHIS 

DIRECTORY  CODEi  12 

I1RECTORT  labeli  determined  by  MOPADS 

TYPE 

CODE 

LABEL 

ItlMBU 

Dl 

«• 

TD-TASK-DATA* 

1 

DL 

- 

R-ADS-RESOURCES* 

• 

i 

DL 

- 

RL-RESOURCE -LABELS* 

1 

DL 

- 

OP-OPERATOR-STATE-VECTOR* 

as  needed 

DL 

- 

EN-ENVIR0NMENTA1.-STATE-VEC* 

1 

DL 

- 

OT-OPERATOR-TYPE* 

1 

DL 

- 

working  ADSM  label -FY  ** 

1 

DL 

- 

working  ADSM  label -TRD*** 

1 

DR 

10 

ACKNOWLEDGEMENT -MESSAGES 

1 

DR 

12 

other  working  ADSM's 

*  These  data  lists  are  Identical 
to  those  In  Code  11  directories. 
Their  descriptions  are  not 
repeated  here. 
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Standard  MOPADS  Terminology 


AIR  DEFENSE  SYSTEM 

A  component  of  Air  Defense  which  includes 
equipment  and  operators  and  for  which 
technical  and  tactical  training  are  required. 
Examples  are  IEAVK  and  the  AN/TSQ-73. 

AIR  DEFENSE  SYSTEM 
MODULE 

Models  of  operator  actions  and  equipment 
characteristics  for  Air  Defense  Systems  in 
the  MOPADS  software.  These  models  are  pre¬ 
pared  with  the  SAINT  simulation  language. 

Air  Defense  System  Modules  include  the 

SAINT  model  and  all  data  needed  to  com¬ 
pletely  define  task  element  times,  task 
sequencing  requirements,  and  human  factors 
influences. 

AIR  SCENARIO 

A  spatial  and  temporal  record  of  aerial 
activities  and  characteristics  of  an  air 
defense  battle.  The  Air  Scenario  includes 
aircraft  tracks,  safe  corridors,  ECM,  and 
other  aircraft  and  airspace  data.  See 
also  Tactical  Scenario. 

BRANCHING 

A  term  used  in  the  SAINT  simulation  lang¬ 
uage  to  meen  the  process  by  which  TASK  nodes 
are  sequenced.  At  the  completion  of  the 
simulated  activity  at  a  TASK  node,  the 
Branching  frou  that  node  determines  which 
TASK  nodes  will  he  simulated  next. 

DATA  BASE  CONTROL 
SYSTEM 

That  part  of  the  MOPADS  software  which 
performs  all  direct  communication  with  the 
MOPADS  Data  Base.  All  information  transfer 
to  and  from  the  data  base  is  performed  by 
invoking  the  subprograms  which  make  up  the 
Data  Base  Control  System. 

DATA  SOURCE 

SPECIALIST 

A  specialist  in  obtaining  and  interpreting 
Army  documentation  and  other  data  needed  to 
prepare  Air  Defense  System  Modules. 

>  V 


ENVIRONMENTAL 
STATE  VARIABLE 


An  element  of  aa  Environmental  State 
Vector. 


ENVIRONMENTAL 

STATE  VECTOR 

An  array  of  values  representing  conditions 
or  characteristics  that  may  affect  more 
than  one  operator.  Elements  of  Environmen¬ 
tal  State  Vectors  may  change  dynamically 

Anri  ng  a  MOPADS  simulation  to  represent 
changes  in  the  environment  conditions. 

MODERATOR  FUNCTION 

A  mathematical/logical  relationship  which 
alters  the  nominal  time  to  perform  an  opera¬ 
tor  activity  (usually  a  Task  Element).  The 
nominal  time  is  changed  to  represent  the 
operator’*  capability  to  perform  the 
activity  based  on  the  Operator's  State 
Vector. 

MOPADS  DATA  BASE 

A  computerized  data  base  designed  specifi¬ 
cally  to  support  the  MOPADS  software.  The 
MOPADS  Data  Base  contains  Simulation  Data 
Set(s).  It  communicates  interactively  with 
MOPADS  Users  during  pre-  and  post-run  data 
specification  and  dynamically  with  the  SAINT 
software  during  simulation. 

MOPADS  MODELER 

An  analyst  who  will  develop  Air  Defense 
System  Modules  and  modify/develop  the 

MOPADS  software  system. 

MOPADS  USER 

An  analyst  who  will  design  and  conduct  simu¬ 
lation  experiments  with  the  MOPADS  software. 

MSAINT  The  Tar i eat  of  SAHJT  used  in  the  MOPADS 

(MOPADS/SAINT)  system.  The  standard  version  of  SAINT  has 

"been  modified  for  MOPADS  to  permit  share¬ 
able  subnetworks  and  more  sophisticated 
interrupts.  The  terms  SAINT  and  MSAINT  are 
used  interchangeably  when  no  confusion  will 
result.  See  also,  SAINT. 
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OPERATOR  STATE 
VARIABLE 


One  element  of  an  Operator  State  Vector. 


OPERATOR  STATE 

VECTOR 

An  array  of  values  representing  the  condi¬ 
tion  and  characteristics  of  an  operator  of 
an  Air  Defense  System.  Many  values  of  the 
Operator  State  Vector  vill  change  dynamically 
during  the  course  of  a  MOPADS  simulation  to 
represent  changes  in  operator  condition. 

OPERATOR  TASK 

An  operator  activity  identified  during 
weapons  system  front-end  analyses. 

SAINT 

The  underlying  computer  simulation  language 
used  to  model*  Air  Defense  Systems  in  Air 
Defense  System  Modules.  SAIHT  is  an  acronym 
for  Systems  Analysis  of  Integrated  Networks 
of  Tasks.  It  is  a  well  documented  language 
designed  specifically  to  represent  human 
factors  aspects  of  man /machine  systems. 

See  also  MSAUJT. 

SIMULATION  DATA  SET 

The  Tactical  Scenario  plus  all  required 
simulation  Initialization  and  other  experl- 
mental  data  needed  to  perform  a  MOPADS 
simulation.  f 

SIMULATION  STATE 

At  any  instant  in  time  of  a  MOPADS  simula¬ 
tion  the  Simulation  State  is  the  set  of 
values  of  all  variables  in  the  M0PAD3  soft¬ 
ware  and  the  MOPADS  Data  Bap. 

SYSTEM  MODULES 

See  Air  Defense  System  Modules. 

TACTICAL  SCENARIO 

The  Air  Scenario  plus  specification  of 
critical  assets  and  the  air  defense  can-' 
figuration  (number,  type  and  location  of 
weapons  and  the  command  and  control  system) . 

Z-4 

TACTICAL  SCENARIO  * 
COMPONENT 

Ac  element  of  a  Tactical  Scenario,  e.g. , 
if  a  Tactical  Scenario  contains  several 
Q-73'  s,  each  one  is  a  Tactical  Scenario 
Component. 

TASK 

See  Operator  Task. 

TASK  ELEMENTS 

Individual  operator  actions  vhich,  vhen 
grouped  appropriately,  make  up  operator 
task3.  Task  elements  are  usually  repre¬ 
sented  by  single  SAIBT  TASK  nodes  in  Air 
Defense  System  Modules. 

TASK  NODE 

A  modeling  symbol  used  in  the  SAIHT  simula¬ 
tion  language.  A  TASK  node  represents  an 
activity;  depending  upon  the  modeling  cir¬ 
cumstances,  a  TASK  node  may  represent  an 
individual  activity  such  as  a  Task  Element, 
or  it  may  represent  an  aggregated  activity 
such  as  an  entire  Operator  Task. 

TASK  SEQUENCING 
MODERATOR 

FUNCTION 

A  mathematical/logical  relationship  vhich 
selects  the  next  Operator  Task  vhich  an 
operator  vill  perform.  The  selection  is 
based  upon  operator  goal  seeking  character¬ 
istics. 

MOPADS  Abbreviations 

DBCS 

Data  Base  Control  System. 

DBAP 

Data  Bdse  Application  Programs 

DBF 

Data  Base  File. 
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I.  PURPOSE 


This  document  describes  a  set  of  utility  programs  used  by  the 
MOPADS  software  to  implement  the  specific  data  base  structure  of 
MOPADS.  The  MOPADS  Data  Base  Control  System  (DBCS),  Polito  (1983a), 
is  a  set  of  programs  that  manage  the  data  base  files  (DBF).  The 
DBCS,  however,  is  generic  in  the  sense  that  nothing  in  these  pro¬ 
grams  is  unique  to  MOPADS.  The  particular  data  and  its  organiza¬ 
tion  in  a  MOPADS  data  base  is  documented  in  Polito  (1983b).  The 
Data  Base  Applications  Programs  (DBAP),  which  are  dicussed  here, 
use  the  DBCS  programs  to  implement  and  access  the  particular  DBF 
discussed  in  Polito  (1983b). 

Thus,  the  DBAP  implements  high  level  data  access  functions 
for  the  MOPADS  modeler  to  use  rather  than  requiring  lowel  level 
data  base  accesses.  For  example,  the  DBAP  has  a  program  to  retrieve 
information  from  a  operator's  operator  state  vector  directly.  The 
modeler  could  accomplish  the  same  thing  bv  making  direct  calls  to 
the  DBCS,  but  this  latter  would  require  that  the  modeler  know 
details  of  how  data  is  stored  in  the  DBF.  The  DBAP  masks  the 
modeler  from  having  to  know  this  low  level  information  which  is  not 
relevant  to  his  data  access  requirements.  Furthermore,  many  such 
high  level  functions  involve  intricate  combinations  of  low  level 
functions  that  would  be  a  burden  to  reprogram  each  time  they  were 
required. 


This  is  a  reference  document  intended  for  MOPADS  modelers  who 
must  extend  or  revise  the  MOPADS  software.  The  MOPADS  program 
suffix  for  the  DBAP  is  "A."  All  of  the  subprogram  names  and  vari¬ 
ables  in  labelled  COMMON  in  the  DBAP  end  with  the  letter  "A. "  Note 
that  not  all  programs  in  MOPADS  that  end  with  ''A"  are  part  of  the 
DBAP.  SAINT  and  programs  in  FFIN2,  Polito  (1983c),  were  written 
before  MOPADS  and  do  contain  some  programs  that  end  with  the  letter 
"A. " 
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II.  DATA  STRUCTURE  DESCRIPTION 


The  DBAP  is  a  collection  of  more  or  less  Unrelated  subprograms 
that  perform  a  variety  of  functions  for  the  MOPADS  modeler.  There¬ 
fore,  there  is  no  unified  data  structure  that  is  internal  to  the 
DBAP.  All  information  is  exchanged  through  formal  subprogram  para¬ 
meters. 

The  structure  of  the  data  files  created  by  the  DBCS  is  dis¬ 
cussed  in  Polito  (1983a)  and  the  contents  of  the  DBF  used  by  MOPADS 
is  presented  in  detail  in  Pdlito  (1983b).  The  contents  of  the  single 
labeled  COMMON  area  contained  in  the  DBAP  is  discussed  in 
SECTION  VIII. 


I 


i 

I 


S* 


III. 


OVERVIEW  OF  THE  FLOW  OF  CONTROL 


The  DBAP  programs  are.  generally  intermediaries  "between  the 
DBCS  and  the  programs  which  implement  the  MOPADS  User  Interface  and 
the  Air  Defense  System  Modules.  DBAP  programs  are  used  extensively 
by  both  the  User  Interface,  Polito  (1983d),  and  the  SAINT  simula¬ 
tion  phases  of  MOPADS.  See  Polito  (I983e)  for  a  description  of  this 
software  organization. 

DBAP  programs  normally  are  called  by  these  external  programs 
and  in  turn  call  other  programs  in  the  DBCS,  MOPADS/UTIL,  Polito  & 
Goodin  (1983),  and,  in  some  cases,  FFIN2,  Polito  (1983c).  DBAP 
programs  seldom  call  other  programs  in  the  DBAP,  and  programs  called 
from  the  DBAP  do  not  in  turn  call  other  programs  in  the  DBAP. 


IV.  EXTERNAL  FILE  USAGE 


The  DBAP  operates  directly  on  only  three  files,  and  none  of 
these  are  opened  or  closed  by  DBAP  programs.  These  files  are  the 
following: 

1.  MOFALS  Line  Printer  Output 

2.  User  Interface  Interactive  Input 

3.  User  Interface  Interactive  Output 

The  line  printer  output  file  is  used  only  for  error  processing 
which  will  be  discussed  in  Section  VII.  The  interactive  input  and 
output  files  are  used  only  by  subroutine  CREATA  to  request  informa¬ 
tion  while  creating  a  new  MO PADS  DBF. 

The  interactive  input  and  output  unit  numbers  are  passed  to 
the  DBAP  as  formal  parameters.  The  line  printer  file  unit  number 
is  maintained  in  COMMON,  but  it  is  initialized  through  a  subprogram 
call.  All  of  these  files  are  sequential,  formatted  files. 

To  summarize,  the  DBAP  has  no  responsibility  to  open,  clo^e, 
or  otherwise  manage  any  files.  Unit  numbers  of  all  files  which  it 
reads  or  writes  are  passed  to  it  through  subprogram  parameters. 


V.  SUBPROGRAM  DESCRIPTIONS 


The  following  pages  contain  description  of  all  subprograms  that 
are  part  of  the  DBAP.  Each  program  description  contains  an  explana¬ 
tion  of  its  purpose,  parameters,  and  alternate  returns. 


SUBROUTINE  APOPTA(IOPT,IVL,NIV,RVL,NRV> 

C— NOOULEl  NOPADS  DATA  BASE  APPLICATION  PROGRAMS 
C— REFERENCE!  NOPADS  VOLUME  S.IB 
C— PURPOSE: 

C  APOPTA  SETS  OPTIONS  FOR  THE  DBAP 
C 

C— INPUT  PARAMETERS! 

C  IOPT-PPTIOM  NUHBERlSEE  BELOU) 

C  IVL(NIV)-INTE6ER  VALUES  FOR  OPTIONS 

C  RVL(NRV)-REAL  VALUES  FOR  OPTIONS 

C 

C  OPTIONS 

C  - 

C  1  OUTPUT  FILE  NUMBER  (  IVLC1)  ) 

C 


SUBROUTINE  ASROUA(NROU,NR,IDBA, ROU, KERR,*) 

C— MODULE:  HOPADS  BATA  BASE  APPLICATION  PROGRAMS 
C ‘■"-REFERENCE l  HOPADS  VOLUME  5. TO 
C— PURPOSE! 

C  TO  RETURN  A  ROU  OF  AN  AIR  SCENARIO  TRACK  DATA  LIST. 

C —-INPUT  PARAMETERS! 

C  NROU-THE  DESIRED  ROU  NUMBER 

C  NR-THE  NUMBER  OF  ELEMENTS  IN  A  ROU 

C— INPUT/CUTPUT  PARAMETERS: 

C  ID8A(2)-THE  DBAA  OF  THE  TRACK  DATA  BATA  LIST  IN  THE  AIR  SCENARIO 
C— OUTPUT  PARAMETERS: 

C  R3U(NR)-AN  ARRAT  TO  HOLD  THE  VALUES  IN  THE  SPECIFIED  ROU. 

C  SEE  THE  DB  DESCRIPTION  FOR  ’AIRCRAFT-TRACKS-HOSTILE 

C  (FRIENDLY) (OTHER)’  FOR  THE  CONTENTS  OF  ROU. 

C  KERR-ERROR  CODE 

C  O-NO  ERROR 

C  t-RDU  NROU  DOFS  NOT  EXIST 

C  2-NR0U.LE.0 

C—  ALTERNATE  RETURNS! 

C  l-KERR.NE.O 


I  £ 


SUBROUTINE  CCDLAUQPT, NROU,  1DRF1I, ROU) 

G — MODULE:  MOPADS  DATA  BASE  APPLICATION  PROGRAMS 

C— REFERENCE!  NOPADS  VOLUME  5.18 

C--PURPOSE< 

C  CCDLA  MANIPULATES  THE  'COPY-COUNTER"  DL  OF  A  SIMULATION  DATA  SET 

C  CCDLA  ASSUMES  THE  DBAA  OF  THE  COPY  COUNTER  DL  IS  IN  COLUMN  3 

C  OF  IDRF1 I.  THE  COPY  COUNTER  HAS  2  COLUMNS.  FOR  ROU  N, 

C  COL.  1  HAS  VALUE  NOOOO+I  UHICH  MEANS  I  COPIES  OF  THE  ADSM 

C  WITH  BASIC  ACN  N*1000  HAVE  BEEN  CREATED (BUT  NEED  NOT  STILL 

C  EXIST.)  COLUMN  2  IS  THE  CURRENT  NUMBER  OF  COPIES  THAT  DO 

C  EXIST. 

C— INPUT  PARAMETERS! 

C  IOPT-OPTION 

C  O-RETURN  CONTENTS  OF  ROU  NROU  ONLY. 

C  1-ADD  ONE  TO  BOTH  COLUMNS  OF  ROU  NROU  AND  RETURN  RESULTS 

C  'ROU'. 

C  2-SUBTRACT  1  FROM  COLUMN  2  OF  ROU  NROU.  DO  NOTHING  IF 

C  COLUMN  2  IS  ZERO.  RETURN  RESULTS  IN  'ROU' 

C  NROU-THE  ROU  NUttBtR  TO  PROCESS 

C--INPUT/OUTPUT  PARAMETERS! 


IN 


1DRF1 I(4,3)-DRAA'S 

COL.  1-  BRAA 


C 
C 
C 
C 

C  COL.  2- 

C 

C  COL.  3- 

C 

C— OUTPUT  PARAMETERS: 


OF  THE  SIMULATION  DATA  SET  ON  A 
DIRECT  LINE  UP  THE  DR  TREE  FROM  THE 
CURRENT  DR. 

DRAA  OF  THE  COMMAND  AND  CONTROL  DR 
ON  A  DIRECT  LINE  UP  FROM  THE  CURRENT 
DiAA  OF  THE  COPY  COUNTER  DL  OF  THE 
SIMULATION  BATA  SET  IN  COL.  1. 


DR. 


ROU < 2 ) — CONTEMTS  OF  ROU  NROU  AFTER  IOPT  IS  PROCESSED. 


SUBROUTINE  CENCA  (NECCf LABEL ,*) 

C 

C— MODULE:  MOPADS  DATA  BASE  APPLICATION  PROGRAMS 
C — REFERENCE:  MOPADS  VOLUME  5.18 

C**PURPQSE:  THIS  SUBROUTINE  IS  USED  TO  DECODE  INTEGER  INDEX  VALUES 
C  INTO  THEIR  CHARACTER  STRING  EQUIVALENTS  (LABELS) . 

C 

C** INPUT  PARAMETERS:  NECC* INTEGER  VALUE  TO  BE  DECODED 
C 

C*»OUTPUT  PARAMETERS:  LABEL*DECODED  CHARACTER  STRIN6 
C 
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C*«ALT£RMATE  RETURNS:  THE  SIN6LE  ALTERNATE  RETURN  OCCURS  IF  NECC 
C  CONTAINS  AN  INTE6ER  COMPONENT  THAT  CAN  NOT  BE 

C  DECODED.  FOR  EXAMPLE, INDEX  VALUES  OF  LESS  THAN 

C  OR  EQUAL  TO  00, OR  6REATER  THAN  36  CAN  NOT  BE 

C  DECODED.  ALSn,  IF  LABEL  IS  NOT 

C  LONC  ENOUGH  TO  HOLD  THE  CHARACTERS. 

C 


SUBROUTINE  CHX6LA(I6L,I0PR,K6L» 

C— MODULE:  MOPADS  BATA  BASE  APPLICATION  PR06RAMS 
C— REFERENCE:  MOPADS  VOLUME  5.18 
C— PURPOSE: 

C  CHKGlA  WILL  DETERMINE  IF  A  SPECIFIED  OPERATOR  HAS 

C  A  PARTICULAR  GOAL. 

C—INPUT  PARAMETERS: 

C  ISL-A  60AL  NUMBER.  CHKGLA  U1LL  CHECK  TO  SEE  IF  THE  OERATOR 
C  HAS  THIS  60AL 

C— INPUT/OUTPUT  PARAMETERS: 

C  I0PR(2)-DBAA  OF  THE  OPERATOR 

C— OUTPUT  PARAMETERS: 

C  K6L-G0AL  STATUS 

C  1-  THE  OPERATOR  HAS  THE  GOAL 

C  2-  THE  OPERATOR  DOES  NOT  HAVE  THE  60AL 


4  SUBROUTINE  CLRSTA(IPOP) 

C— MODULE:  MOPADS  DATA  BASE  APPLICATION  PROGRAMS 
C— REFERENCE:  MOPADS  VOLUME  5.18 
C— PURPOSE: 

C  CLRSTA  UILL  CLEAR  (EMPTY)  AN  OPERATOR'S  TASK  STACK. 
C — INPUT  PARAMETERS: 

C  IDOP-THE  OPERATOR'S  ID 


SUBROUTINE  CPDLA(NDBF,NDBT, ID,NID,IDBAF,IDRT,IDBAT,IERR,*> 

C — MODULE:  HOPADS/UI 
C — REFERENCE:  MOPADS  VOL.  5.12 
C— PURPOSE: 

C  CPDLA  UILL  COPT  A  DL  FROM  ONE  DR  TO  ANOTHER  U1TH  REPLACEMENT. 
C 

C— INPUT  PARAMETERS: 

C  NDBF-DBO -WORKING, 2-REFERENCE)  OF  THE  DL  TO  BE  COPIED 
C  ND8T-DB< AS  ABOVE)  OF  THE  DR  TO  BE  COPIED  TO. 

C  ID(NID)-ID  OF  THE  DL  IN  THE  NEU  DR 
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C~ INPUT/OUTPUT  PARAMETERS! 

C  IDBAF(2)-DBAA  OF  THE  DL  THAT  IS  TO  BE  COPIED 

C  IDRT(4)-DRAA  OF  THE  DR  TO  RECEIVE  A  COPY  OF  THE  DL 
C— OUTPUT  PARAMETERS! 

C  IDBAT<2)-DBAA  OF  THE  COPY  OF  THE  DL  OH  THE  "TO”  PR. 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  .NE.O-BBCS  ERROR  CODE 

C— ALTERNATE  RETURNS! 

C  J-IERR.NE.O 


SUBROUTINE  CPDRA(NDBF,NDBT, ID, NID, LABEL, IDRF,IDROT,IBP.T,IERR,*) 
C — MODULE!  MOPADS  DATA  BASE  APPLICATION  PROGRAMS 
C— REFERENCE:  MOPADS  VOLUME  5.18 

Q--PURPQ5E . 

C  CPDRA  U ILL  COPY  A  DR  FROM  ONE  DB  TO  ANOTHER  UITH  REPLACEMENT 
C  (OR  UITKIN  ONE  DB).  THE  DR  MAY  OUN  DL'S  BUT  NO  DR'S.  MORE 

C  CORRECTLY,  ONLY  THE  OWNED  DL'S  WILL  BE  COPIED. 

C— INPUT  PARAMETERS: 

C  NDBF-"FROMH  DB  (1-UORKING,  2-REFERENCE) 

C  NDBT-"TO"  DB 

C  I D < N I D ) -THE  ID  OF  THE  DR  DN  THE  'TO'  DIRECTORY 

C  LABEL-(CHARACTER)  LABEL  OF  THE  DR  ON  THE  'TO'  DR 

C— INPUT/OUTPUT  PARAMETERS: 

C  IDRF(4)-DRAA  OF  THE  DR  TO  BE  COPIED 
C  IDR0T(4)-DRAA  OF  THE  QUNER  DIRECTORY  ON  NDBT 

C— OUTPUT  PARAMETERS! 

C  IDRT(4)-DRAA  OF  THE  COPIED  DIRECTORY  ON  NDBT 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  .NE.O-DBCS  ERROR  CODE 

C — ALTERNATE  RETURNS: 

C  1-IERR.NE.O.  IF  A  NON-DBCS  ERROK  OCCURS,  ALTERNATE  RETURN 
C  1  UILL  BE  TAKEN  UITH  1ERR=0. 


SUBROUTINE  CREATA(NDB, JIN, JOUT,IERR,*) 

C— MODULE:  MOPADS  DATA  BASE  APPLICATION  PROGRAMS 
C— REFERENCE:  MOPADS  VOLUME  5.18 
C— PURPOSE: 

C  CREATA  UILL  CREATE  THE  SHELL  OF  A  MOPADS  DATA  BASE  ON  A  NEW 
C  DB  FILE.  IT  ASSUMES  THAT  THE  DB  FILE  IS  VIRGIN  AND  WRITES 
C  ON  IT.  THEREFORE,  ANY  INFORMATION  UHICH  MAY  HAVE  BEEN  ON 

C  THE  FILE  UILL  BE  LOST.  CREATA  UILL  SET  URITE  PERMISSION 

C  ON  THE  FILE  (H0DED=2) 
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C— -INPUT  PARAMETERS! 

C  NOB-DATA  BASE! 1 -WORKING, 2-REFERENCE) 

C  JIN-INPUT  FILE 

C  JOUT-OUTPUT  FILE 

C— OUTPUT  PARAMETERS: 

C  IERR-ERROR  CODE 

C  O-NO  ERROR 

C  .NE.O-DBCS  ERROR  CODE.  CREATA  WILL  CLOSE  NDB  BEFORE 

C  RETURNINS. 

C— ALTERNATE  RETURNS: 

C  1-1 ERR . NE . 0 


SUBROUTINE  ERRQRA(MSG, NMSG,SUBP, IPAR, INPAR, PAR, NPAR, IDA) 

C— MODULE:  MOPADS  DATA  BASE  APPLICATION  PROGRAMS 

C— REFERENCE:  MOPADS  VOLUME  5.18 

C--PURPOSE: 

C  ERRORA  WILL  PROCESS  RUN  TIME  ERRORS  UITH  DATA  BASE  ACCESSES 

C  THAT  INDICATE  FAULTY  OR  MISUSED  MOPADS  DATA  BASES.  AS 

C  COMPLETE  A  DUMP  AS  POSSIBLE  WILL  BE  DONE  TO  DIAGNOSE  THE 

C  PROBLEM.  ERRORA  ASSUMES  THE  WORKING  DB,  AND  IT  WILL  TERMINATE 

C  EXECUTION. 

C— INPUT  PARAMETERS: 

C  MS6<NMSG) -CHARACTER  ARRAY  UITH  ERROR  MESSAGE.  EACH  ELEMENT 

C  WILL  BE  TREATED  AS  A  ROW  OF  AN  ERROR  MESSAGE. 

C  SUBP-CHARACTER  VARIABLE  UITH  THE  NAME  OF  THE  CALLING  PROGRAM 
C  IPAR (INPAR) -INTEGER  ARRAY  TO  PRINT  IF  INPAR  .GT.  0 

C  PAR(NPAR)-  REAL  ARRAY  TO  PRINT  IF  NPAR  .GT.O 

C--INPUT/OUTPUT  PARAMETERS: 

C  IDA ( 4 ) - THE  DRAA  OR  DBAA  OF  THE  OFFENDING  DR  OR  DL.  IF  IDA  IS 

C  A  DBAA  FOR  A  DL,  IT  NEED  BE  DIMENSIONED  ONLY  TO  2. 


SUBROUTINE  EVLPA<KGOAL,GS,IDBO?,KASE,GPRI,*) 

—MODULE:  MOPADS  DATA  BASE  APPLICATION  PROGRAMS 

—REFERENCE:  MOPADS  VOLUME  5. 18 

—PURPOSE: 

EVLPA  UILL  EVALUATE  THE  GOAL  PRIORITY  FUNCTION  FOR  A  PARTICULAR 
GOAL  AND  OPERATOR. 

—  INPUT  PARAMETERS: 

KGOAL-THE  GOAL  NUMBER  TO  EVALUATE 
GS-THE  GOAL  STATE  FOR  GOAL  KGOAL 
— INPUT/OUTPUT  PARAMETERS: 

IDB0P(2)-DBAA  OF  THE  OPERATOR 


Z-15 


c- 

c 

c 

c 

c 

c 

c 

c- 

c 


OUTPUT  PARAMETERS: 

KASE-OUTPUT  CONDITION 

1 - PRIORITY  CALCULATED  AD 3  STORED  IN  GPR1 

2- THE  OPERATOR  DOES  NOT  HAVE  60AL  KGOAL.  GPRI*0. 

3- KGOAL  IS  INVALID! I. E.  .LE.O  OR  .GT.  THE  MAX  NUMBER  OF 
60ALS) 

6PRI-G0AL  PRIORITY  FOR  GOAL  KGOAL 
ALTERNATE  RETURNS: 

1 -KASE-3 
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c 

c 

c 

C  ! 
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SUBROUTINE  FNDAKA! IDOP,IELL,IREL, I VAL, NCNDS, HCOL,MSID,MSAA,NCOL> 
MODULE:  MOPADS  DATA  BASE  APPLICATION  PROGRAMS 
REFERENCE:  MOPADS  VOLUME  S.18 
PURPOSE: 

FNDAKA  MILL  FIND  ACKNOWLEDGMENT  MESSAGES  BEL0N6ING  TO  A 
PARTICULAR  OPERATOR  THAT  SATISFY  SPECIFIED  CONDITIONS. 

INPUT  PARAMETERS: 

IDOP-THE  OPERATOR'S  ID 
IELKNCN5S), 

IREL1NCNDS), 

IVAL(NCNDS) -CONDITIONS  TO  CHECK  FOR  THE  MESSAGE  ID. 

ELEMENT  IELL(-)  OF  THE  MESSAGE  MUST  RELATE 
TO  IVAL(-)  WITH  THE  RELATION  IREL(-). 

IELL(-)  HAY  HAVE  THE  VALUES: 

3- A  CONDITION  ON  THE  FUNCTION  TYPE 

4- A  CONDITION  ON  THE  SUBTYPE 

5- A  CONDITION  ON  THE  MESSAGE  PRIORITY 

VALUES  FOR  IREL(-)  ARE: 
t-LT 

2- LE 

3- EQ 

4- GE 

5- 6T 

6- NE 

A)  ALL  NCNDS  CONDITIONS  MUST  BE  SATISFIED  FOR 
AN  ACKNOWLEDGMENT  MESSAGE  TO  BE  FOUND  BY 
FNDAKA. 

I)  IF  NCN0S=C,  ALL  ACKNOWLEDGMENT  MESSAGES 
BELONGING  TO  OPERATOR  IDOP  WILL  BE  FOUND 

C)  NCNDS  NAY  NOT  BE  GREATER  THAN  6 

D)  EXAMPLE:  NCNDS=2 

I ELL ( 1 )*3,  IR!1l<1>=3,  IVAL<1)*1 
IELL(2)=4,  IREL(2)-4,  1VAL(2)*8 


c 

C  THE  ABOVE  EXAMPLE  WILL  FIND  ONLY 

C  COWHAND  MESSAGES (FUNCTION  TYPE*) )  WITH 

C  SUBTYPE  .BE.  t 

C 

C  HCOL-LENGTH  OF  KSIO  AND  HSAA  ARRA  S 
C— OUTPUT  PARAMETERS: 

C  HSIB(SrHCOL)-NESSAGE  ID'S  OF  ALL  MESSAGES  FOR  OPERATOR  IDOP 
C  THAT  SATISFY  THE  CONDITIONS. 

C  HSAA(2,MCGL)-DATA  BASE  ADDRESSES  OF  ALL  MESSAGES  IN  HSID 
C  NCOL-NUMBER  OF  MESSAGES  FOUND. 

C  O.LE.NCOL.LE.HCOL.  FNDAKA  UILL  GENERATE  AN  ERROR  IF 

C  THE  HUMBER  OF  MESSAGES  IS  GREATER  THAN  NCOL. 


SUBROUTINE  FNDNSA<lDOP,IELL,IREL,IVAL,NCNDS,HCOLfMSID, HSAA, NCOL) 
C — MODULE*  HOPADS  DATA  BASE  APPLICATION  PROGRAMS 
C— REFERENCE:  HUPADS  VOLUME  5.18 
C— PURPOSE: 

C  FMDttSA  UILL  FIND  MESSAGES  BELONGING  TO  A  PARTICULAR  OPERATOR 

C  THAT  SATISFY  SPECIFIED  CONDITIONS. 

C— INPUT  PARAMETERS: 

C  IDOP-THE  OPERATOR'S  ID 

C  IELL(NCHDS) , 

C  IREL(NCNDS) , 

C  IVAL(NCNDS) -CONDITIONS  TO  CHECK  FOR  THE  MESSAGE  ID. 

C  ELEMENT  IELL(-)  OF  THE  MESSAGE  MUST  RELATE 

C  TO  IVAL(-)  WITH  THE  RELATION  IREL(-). 

C  IELL(->  HAY  HAVE  THE  VALUES: 

C  3-A  CONDITION  ON  THE  FUNCTION  TYPE 

C  4-A  CONDITION  ON  THE  SUBTYPE 

C  5-A  CONDITION  ON  THE  NESSAGE  PRIORITY 

C 

C  VALUES  FOR  IREL(-)  ARE: 

C  t-LT 

C  2-LE 

C  3-EQ 

C  4-GE 

C  5-GT 

C  6-NE 

C 
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ALL  NCNDS  CONDITIONS  MUST  BE  SATISFIED  FOR 
A  MESSAGE  TJ  BE  *TUND  BY  FNDHSA 
IF  NCNDS=0,  ALL  MESSAGES  BELONGING  TO 
OPERATOR  ISOP  UILL  BE  FOUND 
NCNDS  NAY  NOT  BE  6REATER  THAN  6 
EXAMPLE:  NCHDS-2 
IELLd )*3,  2REL < 1 )*3f  2VAL( 1 )  =  1 
IELL<2)*<,  IREL(2)Mf  2VAL(2)-3 
C 

C  THE  ABOVE  EXAMPLE  UILL  FIND  ONLY 

C  COMMAND  M£SSA6ES( FUNCTION  TYPE=1 )  UITH 

C  SUBTYPE  .6E.  8 

C 

C  HCOL-LENGTH  OF  MSID  AND  MSAA  ARRAYS 
C--OUTPUT  PARAMETERS! 

C  MSID ( 5, HCOL) -MESSAGE  ID'S  OF  ALL  MESSAGES  FOR  OPERATOR  IDOP 
C  THAT  SATISFY  THE  CONDITIONS. 

C  MSAA (2r (1C0L > -DATA  BASE  ADDRESSES  OF  ALL  MESSAGES  IN  MSID 
C  NCOL-NUMBER  OF  MESSAGES  FOUND. 

C  O.LE.MCOL.LE.HCOL.  FNDMSA  UILL  6ENERATE  AN  ERROR  IF 

C  THE  NUMBER  OF  MESSAGES  IS  6REATER  THAN  MCOL. 


SUBROUTINE  FTKAA<NCUR,NRQU) 

C— MODULE:  MOPADS  DATA  BASE  APPLICATION  PROGRAMS 
C— REFERENCE:  MOPADS  VOLUME  5.1 8 
C— PURPOSE: 

£8,  C  FTKAA  UILL  FIND  AN  UNUSED  ROU  IN  THE  “TRACK  DATA*  DL  OF  A 

C  PARTICULAR  ADSH 

C— INPUT  PARAMETERS: 

C  NCUR-ADSM  COPY  ROU  NUMBER 

C— OUTPUT  PARAMETERS: 

C  NROU-AN  AVAILABLE  ROU 


j 

SUBROUTINE  GETEVA(IDE,N,NEE,KErXE) 

C— MODULE:  MOPADS  DATA  BASE  APPLICATION1  PROGRAMS 
C— REFERENCE:  MOPADS  VOLUME  5.18  I 

C— PURPOSE: 

C 

C  GETEVA  RETURNS  THE  VALUES  OF  SPECIFIED  HUMAN  FACTORS  ELEMENTS  OF 

C  ENVIRONMENTAL  STATE  VECTORS.  IT  IS  CALLED  FROM  THE  HUMAN  FACTORS 

C  MODULE. 

C 
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C— INPUT  PARAMETERS! 

C  IDE <  M ) - T HE  OBAA  OF  THE  ESV 

C  NEE(KE)-THE  DESIRED  ELEMENT  NUMBERS.  E.6.  NEE(2)«?  IMPLIES  THAT 
C  HUMAN  FACTORS  ELEMENT  7  OF  THE  ESV  IS  TO  PE  RETURNED. 

C— OUTPUT  PARAMETERS! 

C  XE<KE)-THE  CURRENT  VALUES  OF  THE  ELEMENTS  SPECIFIED  IN  NEE. 

C  E.6.  IF  NEE ( 2 ) s7 ,  THEN  XE(2’;»THE  VALUE  OF  HF  ELEMENT  7. 


SUBROUTINE  QETOVAf ID0,N,N£0,KQ,X0> 

C— MODULE:  HOPADS  DATA  BASE  APPLICATION  PROCRAMS 
C— REFERENCE!  MOPADS  VOLUME  S.18 
C— PURPOSE! 

C  6ET0VA  RETURNS  THE  VALUES  OF  SPECIFIED  HUMAN  FACTORS  ELEMENTS  OF 
C  STATE  VECTORS(OSV) .  IT  IS  CALLED  FROM  THE  HUMAN  FACTORS 
C  MODULE. 

C— INPUT  PARAMETERS! 

C  1 DO < N ) -OBAA  OF  THE  OSV 

C  NEO ( KO > -THE  DESIRED  ELEMENT  NUMBERS.  E.B.  NE0<2>*7  IMPLIES  THAT 

C  HUNAN  FACTORS  ELEMENT  7  OF  THE  OSV  IS  TO  BE  RETURNED. 

C— OUTPUT  PARAMETERS! 

C  XO ( KO) —THE  CURRENT  VALUES  OF  THE  HUMAN  FACTORS  ELEMENTS 

C  SPECIFIED  IN  NEO.  E.6.  IF  NE0(2)>7,  THEN  X0(2)*THE 

C  VALUE  OF  HF  ELEMENT  7. 


SUBROUTINE  GETTSAdQPT,  ITASK,NTS,NTSK,NT,XTSK> 

•  -iiODULE:  HOPADS  DATA  BASE  APPLICATION  PROGRAMS 

— .TEFERENCE:  MOPADS  VOLUME  5.18 

—PURPOSE! 

GETTSA  RETURNS  THE  VALUES  OF  SPECIFIED  TASK  DATA  ELEMENTS. 

IT  IS  CALLED  TO  OBTAIN 

INFORMATION  ABOUT  THE  TASK  BEING  PERFORMED. 

—  INPUT  PARAMETERS! 

IQPT-OPTION 

O-REQUESTINB  TASK  TIME  INFORMATION 

1- REQUESTING  HUMAN  FACTORS  DATA  SPECIFIC  TO  THE  TASK. 

2- REQUESTING  INFORMATION  ON  THE  SKILLS  REQUIRED  TO 
PERFORM  THE  TASK. 

3- REQUESTING  INFORMATION  ON  SYSTEM  RESOURCES  NEEDED. 
ITASK(NTS)-THE  DBAA  OF  THE  TASK  DATA  LIST+TASK  NUMBER. 

ITASKd)  I  (2)  ARE  THE  DBAA.  I  TASK  ( 3 ) =HODE  NUMBER. 
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N TSK ( MT > -THE  DESIRED  ELEMENT  NUM3ERS.  THERE  ARE  4  CASES: 

I0PT*0 — NTSK  NOT  USED 

IOPT»1 — NTSK  CONTAINS  ELEMENT  NUMBERS  OF  THE  TASK 
SPECIFIC  CATEGORIES. 

I OPT =2 — NTSK  CONTAINS  SKILL  NUMBERS 

IOPT-3 — NTSK  CONTAINS  RESOURCE  NUMBERS 
-OUTPUT  PARAMETERS! 

XTSK < NT ) -THE  VALUES  OF  THE  VARIABLES  REQUESTED  IN  NTSK  ABOVE. 

4  CASES: 

I0PT*0~ XTSK(J)  TO  (3)  ARE  DISTRIBUTION  TYPE,  MEAN,  AND 
STANDARD  DEVIATION, 

IOPT*1 — IF<NTSK<2>=3,  XTSK(2)=THE  VALUE  OF  TASK 
SPECIFIC  CATEGORY  3. 

I0PT*2--IF(NTSK(2)=3,  XTSK<2)=THE  HEIGHT  OF  SKILL 
CATEGORY  3  REQUIRED  TO  FERFORM  THE  TASK. 

IF  SKILL  3  IS  NOT  REQUIRED,  XTSK(2)=0  IS 
RETURNED. 

I0PT=3 — IF  «TSK(2»=3,  THEN  XTSK(2)*RES0URCE  PARAMETER 
FOR  RESOURCE  3.  ZERO  IF  RESOURCE  2  NOT  NEEDED. 


SUBROUTINE  GTKAA(NCUR,ID,ICOL,IREL,VAL,NCND,LEN,IDATA,NCL,MORE> 
-MODULE:  MOPADS  DATA  BASE  APPLICATION  PROGRAMS 
-REFERENCE:  MOPADS  VOLUME  S.18 
-PURPOSE: 

GTKAA  IS  USED  TO  LOCATE  TRACK  INFORMATION  IN  AN  ADSM'S 
■TRACK-DATA"  DATA  LIST  THAT  SATISFIES  CERTAIN  CONDITIONS. 
-INPUT  PARAMETERS: 

NCUR-ADSM  COPY  ROU  NUMBER 

IB-ID  OF  THE  OPERATOR.  IF  ID.NE.O,  GTKAA  ONLY  FINDS  TRACKS 
THAT  BELONG  TO  OPERATOR  ID.  IF  ID=0,  ALL  TRACKS  SATISFYING 
THE  CONDITIONS  ARE  FOUND. 

ICOL(NCND) , 

IREL(NCND), 

VAL<NCND)-THE  CONDITIONS  TO  SEARCH  FOR.  TRACK  DATA  IS 
STORED  IN  ROUS  OF  A  MATRIX  IN  THE  DB.  ICOl(-) 

IS  A  COLUMN  NUMBER,  IREL(-)  IS  A  RELATION  CODE, 
AND  VAL(-)  IS  A  VALUE  FOR  COMPARISON.  GTKAA  UILL 
SEARCH  FOR  ROUS  OF  THE  "TRACK  DATA*'  DL  UHOSE 
ICOL(-)  COLUMN  RELATES  TO  VAL(-)  IN  THE  MANNER 
C  SPECIFIED  BY  IREL(-).  IREL(-)  MAY  HAVE  THE 

C  FOLLOUING  VALUES: 
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1- LT 

2- LE 

3- EQ  (TOLERANCE  OF  0.001  IS  USED) 

4- BE 

5- BT 

6- NE  (TOLERANCE  OF  0.001  IS  USED) 

ALL  NCND  CONDITIONS  MUST  BE  TRUE  FOR  A  ROU  TO  BE 
FOUND. 

EXAMPLES  IC0L'2)=4f IREL(2)=5,VAL<2)*2.  UILL 
SEARCH  FOR  ROUS  UHOSE  4-TH  COLUMN 
IS  6REATER  THAN  2. 

IF  NCND=0,  6TKAA  SEARCHES  ONLY  FOR  TRACKS  THAT 
BELONG  TO  OPERATOR  ID.  IF  NCND=0  AND  ID»0, 

6TKAA  RETURNS  ALL  TRACKS. 

8TKAA  CAN  BE  USED  TO  SEARCH  FOR  EMPTY  ROUS  OF 
THE  DL  BY  SENDING  ID=0,IC0L(1 )=1 ,IREL(1 )=3, 

VAL ( 1 )  =  0. ,  AND  NCND“1 .  * 

LEN-THE  NUMBER  OF  COLUMNS  IN  THE  IDATA  ARRAY. 

OUTPUT  PARAHETEkS: 

IDATA(3,LEN)-EACH  COLUMN  CAN  REPRESENT  A  TRACK  THAT  SATISFIES 
THE  ABOVE  CONDITIONS.  FOR  A  PARTICULAR  COLUMN, 

I  DAT  A  < 1 ,-)-ROU  NUMBER  IN  THE  TRACK  DATA 
DATA  LIST  OF  THE  ADSH 
I DAT A (2,-) -COLUMN  IN  NfRACK  FOR  THE  TRACK 
1DA1 A(3,-)-SYM80L  CODE  FOR  THE  TRACK 
NCL-COLUMNS  1  THRU  NCL  OF  IDATA  UILL  CONTAIN  TRACK  DATA 
THAT  SATISFIES  THE  CONDITIONS.  ZERO  IF  NONE. 

H0RE-H0RE=0  IF  IDATA  CONTAINS  ALL  OF  THE  TRACKS  SATISFYING 
THE  CONDITIONS. 

MORE.NE.O  IMPLIES  IDATA  IS  FILLED  AND  MORE  TRACKS  REMAIN 
UHICH  SATISFY  THE  CONDITIONS.  TO  BET  THESE  TRACKS,  CALL 
GTKAA  AGAIN  UITHOUT  CHANGING  THE  VALUE  OF  MORE. 

INITIALLY,  MORE  SHOULD  BE  SET  TO  ZERO  BY  THE  USER. 


SUBROUTINE  uTKBA(NCUR,NROU,IOK,ROU) 

C — MODULE:  MOPADS  DATA  BASE  APPLICATION  PROGRAMS 
C — REFERENCE:  MOPADS  VOLUME  5.18 
C — PURPOSE: 

C  6TKBA  UILL  RETURN  A  ROU  OF  THE  “TRACK-DATA"  DL  FOR  A  SPECIFIED 
C  ADSM 
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C--INPUT  PARAMETERS s 
C  NCUR-ADSM  COPY  ROU  NUMBER 

C  NROU-ROU  OF  THE  DATA  LIST  TO  6ET 

C--OUTPUT  PARAMETERS! 

C  IOK-OUTPUT  CONDITION 

C  t-ROU  NROU  CONTAINED  TRACK  DATA 

C  2-ROU  NROU  DID  NOT  CONTAIN  TRACK  DATA.  THIS  IS  AN  ERROR. 

C  3-ROU  NROU  DOES  NOT  EXIST-BEYOND  END  OF  DATA  LIST 

C  R0UT13)— CONTENTS  OF  ROU  NROU  IF  IQK-1 


SUBROUTINE  GT KC A ( NCUR , I  CODE , NPO IHT  r NCOL , VAL , IOK) 

C — MODULE:  HOPADS  DATA  BASE  APPLICATION  PROGRAMS 
C — REFERENCES  MOPADS  VOLUME  5.18 
C— PURPOSE: 

C  6TKCA  IS  USED  TO  GET  A  SINGLE  ELEMENT  OF  A  ROU  IN  THE 
C  "TRACK  DATA"  DATA  LIST  OF  AN  ADSH. 

C — INPUT  PARAMETERS: 

C  NCUR-ADSM  COPY  ROU  NUMBER 

C  ICODE-HEANING  OF  NPOINT 

C  1 “NPOINT  IS  A  ROU  NUMBER  IN  THE  "TRACK  DATA"  DL1THIS 

C  IS  THE  EFFICIENT  UAY) 

C  2-NPOINT  IS  A  COLUMN  NUMBER  IN  THE  NTRACK  ARRAY( THIS 

C  IS  THE  INEFFICIENT  UAY) 

C  NPOINT-ROU  NUMBER  OR  NTRACK  COLUMN  NUMBER  (SEE  1CODE) 

C  NCOL-COLUMN  NUMBER  OF  THE  ROU  TO  GET 

C— OUTPUT  PARAMETERS: 

C  VAL-VALUE  OF  THE  NCOL-TH  ELEMENT  OF  THE  SPECIFIED 

C  ROU. 

C  IOK-OUTPUT  CONDITION 

C  1-ALL  OK 

C  2-NCOL  NOT  VALID  OR  THE  SPECIFIED  ROU  DOES  NOT  CONTAIN 

C  TRACK  DATA.  VAL  NOT  CHANGED. 


SUBROUTINE  GTSPA(NCUR,IPAR,SYSP) 

C— MODULE:  MOPADS  DATA  BASE  APPLICATION  PROGRAMS 
C— REFERENCE:  HOPADS  VOLUME  5.18 
C — PURPOSE: 

C  GTSPA  UILL  GET  A  SINGLE  SYSTEM  PARAMETER  FROM  THE  ENVIRONMENT 
C  STATE  VECTOR  OF  AN  ADSM. 

C — INPUT  PARAMETERS: 

C  NCUR-COPY  ROU  NUMBER  OF  THE  ADSM 

C  IPAR-SYSTEM  PARAMETER  NUMBER  <1 .LE.IPAR.LE.21 ) 

C--OUTPUT  PARAMETERS: 

C  SYSP-VALUE  OF  THE  SYSTEM  PARAMETER 


$ 
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SUBROUTINE  INIBLA(NDBf IRCF,IRCT,1DBAA,IERR,*) 

C— NODULE:  MOPADS  DATA  BASE  APPLICATIUN  PROGRAMS 
C — REFERENCES  MOPADS  VOLUME  5.13 
C-- PURPOSES 

C  INIDLA  MILL  COPY  A  REAL  OL  ROU(CQLUMN)  TO  ANOTHER  ROU(COLUMN) 
C  OF  THE  SAME  0L 

C 

C— INPUT  PARAMETERS: 

C  NDB-DATA  BASE  < 1-UQRKING,  2-REFERENCE) 

C  IRCF-ROU  OR  COLUMN  TO  BE  COPIED.  IF  IRCF.GT.O,  COPY  ROM  IRCF. 
C  IF  IRCF. LT. 0;  COPY  COLUMN  (-IRCF) . 

C  IRCT-ROU  OR  COLUMN  TO  BE  COPIED  INTO. 

C— INPUT/OUTPUT  PARAMETERS: 

C  IDBAA(2)-DBAA  OF  THE  DL 

C 

C— OUTPUT  PA  .’AMETERS: 

C  IERR  -ERROR  CODE 

C  O-NO  ERROR 

C  .NE.O-DBCS  ERROR  CODE 

C— ALTERNATE  RETURNS: 

C  1-IERR.NE.O 


SUBROUTINE  NCOPYA 

C— MODULE:  HOPADS  DATA  BASE  APPLICATION  PROGRAMS 
C— REFERENCE:  MOPADS  VOLUME  5.18 
C — PURPOSE: 

C  NCOPYA  UILL  EXAMINE  THE  DATA  BASE  AND  FILL  THE  NCQPY  ARRAY. 
C  COLUMNS  3  AND  IFDBM  HAVE  ALREADY  BEEN  FILLED  BY  MSAINT. 

C  NCOPYA  ALSO  FILLS  THE  NOPRI ,NDB4,AND  NMES  ARRAYS 


SUBROUTINE  NECCA  (LABEL, NECC,*) 

C 

C — MODULE:  MOPADS  DATA  BASE  APPLICATION  PROGRAMS 
C— REFERENCES  HOPADS  VOLUME  5.18 

CMPURPOSE:  THIS  SUBROUTINE  CODES  A  CHARACTER  STRING  INTO  AN  INTEGER 
EQUVALENT  BY  CODING  EACH  CHARACTER  IN  THE  STRING  AS  A 
TWO  DIGIT  INTEGER  VALUE. THE  ONLY  CHARACTERS  THAT  MAY  BE 
CODED  ARE  A-Z  AND  0-9. THE  LETTERS  OF  THE  ALPHABET  ARE 
CODED  ACCORDING  TO  THEIR  ORDER  (E.G.  A  IS  CODED  AS  01, D  AS 
OA,F  AS  06, ETC.). THE  DIGITS  1 ,2, 3, A, 5, 6, 7, 8, 9,0  ARE  A 
ASSIGNED  THE  VALUES  OF  27-36  RESPECTIVELY. 
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CMINPUT  PARAMETERS!  LABEL*CHARACTER  STRING  TO  BE  CODED 
C 

C**OUTPUT  PARAMETERS!  NECC-CODED  INTEGER  VALUE  REPRESENTING  THE 
C  CHARACTER  STRING  i LABEL ) 

C 

C**ALTERN ATE  RETURNS!  THE  SINGLE  ALTERNATE  RETURN  OCCURS  IF  THERE  IS 
C  NOT  AN  INDEX  VALUE  FOR  A  PARTICULAR  CHARACTER. 

C 


SUBROUTINE  NFST1A 

C— MODULE:  HOPABS  DATA  BASE  APPLICATION  PROGRAMS 
C— REFERENCE:  MOPADS  VOLUME  S.18 
C— PURPOSE: 

C  NFST1A  IS  CALLED  IMMEDIATELY  AFTER  NCOPYA.  IT  FILLS  THE 

C  NSITE  AND  NFSTOR  ARRAYS  WITH  DATA  FOR  THE  AIR  DEFENSE  UNITS. 

C  IT  DOES  NOT  FILL  NSITE  FOR  PROTECTED  SITES  OR  VIEWERS. 

C  NEITHER  NSITE  NOR  NFSTOR  CAN  BE  COMPLETELY  FILLED  HERE  BECAUSE 

C  OF  REFERENCES  TO  PROTECTED  SITES  AND  VIEWERS. 


SUBROUTINE  NFST2A 

C— MODULE:  MOPADS  DATA  BASE  APPLICATION  PR06RANS 
C— REFERENCE!  MOPADS  VOLUME  5.18 
C— PURPOSE: 

C  NFST2A  FILLS  THE  .TSITE  ARRAY  WITH  COLUMNS  FGR  REMOTE  VIEWERS 


SUBROUTINE  NFST3A 

C— MODULE:  MOPADS  DATA  BASE  APPLICATION  PROGRAMS 
C— REFERENCE:  MOPADS  VOLUME  5.18 
C— PURPOSE: 

C  NFST3A  UILL  FINISH  INITIALIZING  THE  NFSTOR  ARRAY  AND  WILL  LOAD 
C  PROTECTED  SITE  DATA  IN  NSITE.  IT  ALSO  LOADS  OTHER  VALUES 
C  FROM  RUN-DATA. 


SUBROUTINE  POPSTA( IOPT, IDOP, NT, TASKS, NSL,*> 

C— MODULE:  MOPADS  DATA  BASE  APPLICATION  PROGRAMS 
-REFERENCE:  MOPADS  VOLUME  5.18 
—PURPOSE: 

POPSTA  WILL  POP  TASK  DATA  OFF  OF  AN  OPERATOR'S  TASK  STACK. 
THE  STACK  IS  A  LAST-IN-FIRST-OUT  STACK  OF  TASK  DATA. 


C — INPUT  PARAMETERS! 

C  IOPT-OPTION 

C  1-6ET  TASK  DATA  FROM  THE  TASK  STACK  AND  REHOVE  IT 

C  FROM  THE  STACK. 

C  2-GET  TASK  DATA  BUT  LEAVE  IT  OH  THE  STACK1I.E.  EXAMINE 

C  THE  STACK) 

C  1DOP-OPERATOR  ID  NUMBER 

C  NT-NUMBER  OF  COLUMNS  OF  THE  TASKS  ARRAY.  THE  NEXT  HT  TASKS 
C  ON  THE  STACK  UILL  BE  RETURNED  IN  TASKS.  TASKS!-, 1)  WILL 

C  BE  THE  NEXT  TASK  TO  BE  PERFORMED. 

C— OUTPUT  PARAMETERS! 

C  TASKS(5, NT) -ARRAY  TO  HOLD  TASK  DATA  FROM  THE  STACK.  IF 

C  TASKS!-, D.LT.O,  THE  TASK  UAS  PREVIOUSLY  INTERRUPTED 

C  EACH  COLUMN  OF  TASKS  CAN  HOLD  DATA  FOR  ONE  TASK. 

C  NSL-THE  NUMBER  OF  TASKS  RETURNED  IN  TASKS!).  IF  NSL.LT.NT,  IT 
C  MEANS  THAT  FEUER  THAN  NT  TASKS  ARE  ON  THE  STACK.  NSL»0  IF 

C  ALTERNATE  RETURN  1  IS  TAKEN. 

C— ALTERNATE  RETURNS! 

C  1-STACK  EMPTY 


SUBROUTINE  PSHSTA!IDOP,TASKS,NT> 

C— MODULE!  MOPADS  DATA  BASE  APPLICATION  PROGRAMS 
C— REFERENCE!  MOPADS  VOLUME  5. IB 
C— PURPOSE! 

C  PSHSTA  UILL  PUSH  TASK  DATA  ONTO  AH  OPERATOR'S  TASK  STACK. 

C  THE  STACK  IS  A  LAST-IN-FIRST-OUT  STACK  OF  TASK  DATA. 

C— INPUT  PARAMETERS! 

C  IDOP-OPERATOR  IB  NUMBER 

C  TASKS! 3, NT) -ARRAY  OF  TASK  DATA  FOR  THE  STACK.  IF 
C  TASKS!-, D.LT.O,  THE  TASK  IS  BEING  INTERRUPTED. 

C  TASKS! 1 ,NT )  UILL  BECOME  THE  NEXT  TASK  TO  BE  PERFORMED. 


SUBROUTINE  PTKBA(NCUR,NROU,ROU) 

C— MODULE!  MOPADS  DATA  BASE  APPLICATION  PROGRAMS 
C— REFERENCE:  MOPADS  VOLUME  3.18 
C— PURPOSE! 

C  PTKIA  UILL  FILL  A  ROU  OF  THE  "TRACK-DATA"  BATA  LIST  FOR  A 

C  SPECIFIED  ADSM 

C— INPUT  PARAMETERS! 

C  NCUR-ABSN  COPY  ROU  NUMBER 

C  NROU-ROU  TO  FILL 

C  ROU!  ID-VALUES  TO  PUT  IN  ROU  NROU 


SUBROUTINE  PTKCA(NCUR,ICODE, NPOINT, NCQL,VAL,IOK) 

C— MODULE:  HOPADS  DATA  BASE  APPLICATION  PR06RAHS 
C— REFERENCES  HOPADS  VOLUME  5.18 
C— PURPOSE: 

C  PTKCA  IS  USED  TO  CHANGE  A  SINGLE  ELEMENT  OF  A  ROU  IN  THE 

C  "TRACK  DATA"  DATA  LIST  OF  AN  ADSN. 

C — INPUT  PARAMETERS: 

C  NCUR-ADSH  COPY  ROU  NUMBER 

C  ICODE-HEANING  OF  NPOINT 

C  1 -NPOINT  IS  A  ROU  NUMBER  IN  THE  "TRACK  DATA"  DL < THIS 

C  IS  THE  EFFICIENT  UAY) 

C  2-NPOINT  IS  A  COLUMN  NUMBER  IN  THE  NTRACK  ARRAY (THIS 

C  IS  THE  INEFFICIENT  UAY) 

C  NPOINT-ROU  NUMBER  OR  NTRACK  COLUMN  NUMBER  (SEE  1CODE) 

C  NCOL-COLUHN  NUMBER  OF  THE  ROU  TO  CHAN6E 

C  VAL-NEU  VALUE  FOR  THE  NCOL-TH  ELEMENT  OF  THE  SPECIFIED 
C  ROU. 

C— OUTPUT  PARAMETERS: 

C  IOK-OUTPUT  CONDITION 

C  1-ALL  OK 

C  2-NCOL  NOT  VALID  OR  THE  SPECIFIED  ROU  DOES  NOT  CONTAIN 

C  TRACK  DATA. 


SUBROUTINE  PTSPA(NCURt!PAR, SYSP) 

C— MODULE:  HOPADS  DATA  BASE  APPLICATION  PROGRAMS 
C— REFERENCE:  HOPADS  VOLUME  5.18 
C— PURPOSE: 

C  PTSPA  UILL  SET  A  SINGLE  SYSTEM  PARAMETER  FROM  THE  ENVIRONMENT 
C  STATE  VECTOR  OF  AN  ADSH. 

C— INPUT  PARAMETERS: 

C  MCUR-COPY  ROU  NUMBER  OF  THE  ADSH 

C  IPAR-SYSTEN  PARAMETER  NUMBER  < 1 .LE.IPAR.LE.21 ) 

C  SYSP-VALUE  OF  THE  SYSTEM  PARAMETER 


SUBROUTINE  PUTEVA(IDE,N,NEE,KE,XE) 

C— MODULE:  HOPADS  DATA  BASE  APPLICATION  PROGRAMS 

C— REFERENCE:  HOPABS  VOLUME  5.18 

C--PURPOSE: 

C 

C  PUTEVA  SETS  THE  VALUES  OF  SPECIFIED  HUMAN  FACTORS  ELEMENTS  OF 
C  ENVIRONMENTAL  PTATE  VECTORS. 

C 


C — INPUT  PARAMETERS: 

C  1 OE < N ) -THE  DBAA  OF  THE  ESV 

C  NEE(KE)-THE  DESIRED  ELEMENT  NUMBERS.  E.6.  NEE<2)»7  IMPLIES  THAT 
C  HUNAN  FACTORS  ELEMENT  7  OF  THE  ESV  IS  TO  BE  SET. 

C  XE(KE)-THE  NEU  VALUES  FOR  THE  ELEMENTS  SPECIFIED  IN  NEE. 

C  E.G.  IF  NEE(2)*7,  THEN  XE(2)*THE  VALUE  OF  HF  ELEMENT  7. 


SUBROUTINE  PUTOVA< IDO, N,NEO,KQ,XQ> 

C— MODULE:  HOPADS  BATA  BASE  APPLICATION  PR06RANS 
C— REFERENCE:  HOPADS  VOLUME  5. IB 
C— -PURPOSE: 

C  PUTOVA  SETS  THE  VALUES  OF  SPECIFIED  HUMAN  FACTORS  ELEMENTS  OF 
C  STATE  VECTORSTOSV) . 

C— INPUT  PARAMETERS: 

C  IDO(N>-BBAA  OF  THE  OSV 

C  NEO(KO)-THE  DESIRED  ELEMENT  NUMBERS.  E.6.  NEO(2>*7  IMPLIES  THAT 
C  HUMAN  FACTORS  ELEMENT  7  OF  THE  OSV  IS  TO  BE  SET. 

C  XO(KO)-THE  NEU  VALUES  OF  THE  HUMAN  FACTORS  ELEMENTS 
C  SPECIFIED  IN  NEO.  E.6.  IF  NE0(2>»7,  THEN  X0(2)*THE 

C  VALUE  CF  HF  ELEMENT  7. 


SUBROUTINE  PUTTSAUOPT,  ITASK,NTSrNTSK,MT,XTSK> 

C — MODULE:  HOPADS  DATA  BASE  APPLICATION  PR06RAHS 

C— REFERENCE:  HQPAOS  VOLUME  5.18 

C--PURPOSE: 

C  PUTTSA  SETS  THE  VALUES  OF  SPECIFIED  TASK  DATA  ELEMENTS. 

C  IT  IS  CALLED  TO  SET 

C  INFORMATION  ABOUT  THE  TASK  BEING  PERFORMED. 

C 

C— INPUT  PARAMETERS: 

C  IOPT-OPTION 

C  0-SETT1N6  TASK  TIME  INFORMATION 

C  1 -SETTING  HUMAN  FACTORS  DATA  SPECIFIC  TO  THE  TASK. 

C  2-SETTING  INFORMATION  CM  THE  SKILLS  REQUIRED  TO 

C  PERFORM  THE  TASK. 

C  3-SET  TIME  INFORMATION  ON  STSTEH  RESOURCES  NEEDED. 

C  IT  ASK ( NTS ) -THE  DBAA  OF  THE  TASK  DATA  LIST  +  TASK  NUMBER. 

C  ITASK(I)  I  (2)  ARE  THE  DBAA.  ITASK<3)=NCD£  NUMBER. 

C  NTSK ( NT )  —  T HE  DESIRED  ELEMENT  NUMBERS.  THERE  ARE  4  CASES: 

C  IDPT*0— MTSK  NOT  USED 

C  IOPT«1— NTSK  CONTAINS  ELEMENT  NUMBERS  OF  THE  TASK 

C  SPECIFIC  CATEGORIES. 

C  I  OPT  =  2--NTSK  CONTAINS  SKILL  NUMBERS 

C  IOPT«3— NTSK  CONTAINS  RESOURCE  NUMBERS 
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XTSK < MT ) -THE  VALUES  OF  THE  VARIABLES  REQUESTED  IN  NTSK  ABOVE. 

4  CASES: 

I0PT«0— XTSKU )  TO  (3)  ARE  DISTRIBUTION  TYPE,  KEAN,  AND 
STANDARD  DEVIATION. (ALL  MUST  BE  SET) 

IOPT»1~ IF(NTSK<2>«3,  XTSK(2)«THE  VALUE  OF  TASK 
SPECIFIC  CATEGORY  3. 

I0PT»2~ IF(NTSK(2)*3,  XTSK(2)*THE  UEI6HT  OF  SKILL 
CATEGORY  3  REQUIRED  TO  PERFORM  THE  TASK. 

IF  SKILL  3  IS  NOT  REQUIRED,  SEND  XTSK<2>*0. 

NEU  SKILLS  HAY  NOT  IE  ADDED,  BUT  UEI6HTS  OF 
EXISTING  SKILLS  HAY  BE  CHAN6ED. 

I0PT*3 — IF  NT3K<2>«3,  THEN  XTSK(2)«RES0URCE  PARAMETER 
FOR  RESOURCE  3.  ZERO  IF  RESOURCE  2  NOT  NEEDED. 
NEU  RESOURCES  HAY  NOT  BE  ADDED,  BUT  PARAMETERS 
OF  EXISUN6  RESOURCES  HAY  BE  CHANGED. 


SUBROUTINE  RECHSA(IOPT,IDOP,NDATA,HSAA, CHARS, DATA, HSID,NLEN) 

C— NODULE:  HOPADS  DATA  BASE  APPLICATION  PROGRAHS 
C— REFERENCE:  HOPADS  VOLUME  5. IB 
C— PURPOSE: 

C  RECHSA  WILL  RETRIEVE  A  HESSAGE.  SEE  SUBROUTINES  SNDMSA  AND 
C  FNDHSA  FOR  MORE  INFORMATION. 

C— INPUT  PARAMETERS: 

C  IOPT-OPTION 

C  1 -RETRIEVE  HESSAGE  AND  DELETE  IT  FROM  THE  MESSAGE  DIRECTORY 

C  2-RETRIEVE  HESSAGE  BUT  DO  HOT  DELETE  IT(  I.E.  EXAHINE  IT 

C  ONLY) 

C  IDOP-OPERATOR  ID  UHO  IS  TO  RECEIVE  THE  HESSAGE 

C  NBATA-LENGTH  OF  THE  DATA  ARRAY 

C— INPUT/OUTPUT  PARAMETERS: 

C  HSAA(2)-DATA  BASE  ADDRESS  OF  THE  HESSAGE.  SEE  FNDHSA. 

C— OUTPUT  PARAMETERS: 

C  CHARS< 10)-MESSA6E  CHARACTERISTICS.  SEE  SNDMSA. 

C  DATA(NDATA)-ARRAY  TO  HOLD  MESSAGE 

C  Y4SID(5>— MESSAGE  ID 

C  NLEN-NESSAGE  LENGTH.  ELEMENTS  1  TU  NLEN  OF  'DATA"  HOLD  THE 
C  HESSA6E.  IF  NLEN.LT.O,  THEN  THE  HESSAGE  IS  TOO  L0N6 

C  TO  FIT  IN  'DATA'.  -NLEN  IS  THE  TOTAL  HESSAGE  LENGTH  AND 

C  THE  FIRST  NDATA  ELEMENTS  ARE  RETURNED  IN  'DATA'. 


SUBROUTINE  RETAKA(IOPT,NCOP,NDATA,MSAA, CHARS, DATA, NLEN) 

C  --MODULE *  MOPADS  DATA  BASE  APPLICATION  PROGRAMS 
C— REFERENCE:  MOPADS  VOLUME  5.18 

£..pygpQg£. 

C  RETAKA  UILL  RETRIEVE  AN  ACKNOULEDGMENT  MESSAGE.  SEE  SUBROUTINES 
C  SVAKA  AND  FNDAKA  FOR  MORE  INFORMATION. 

C— INPUT  PARAMETERS: 

C  IOPT-OPTION 

C  1 -RETRIEVE  MESSAGE  AND  DELETE  IT  FROM  THE  MESSAGE  DIRECTORY 

C  2-RETRIEVE  MESSAGE  BUT  DO  NOT  DELETE  IT(  I.E.  EXAMINE  IT 

C  ONLY) 

C  NCOP-COPY  ROU  NUMBER  OF  ACKNOULEDGHENT-HESSAGE  DIRECTORY 
C  NDATA-LENGTH  OF  THE  DATA  ARRAY 

C— INPUT/OUTPUT  PARAMETERS: 

C  HSAA(2)-DATA  BASE  ADDRESS  OF  THE  MESSAGE.  SEE  FNDAKA. 

C— OUTPUT  PARAMETERS: 

C  CHARS(10)-M£SSAGE  CHARACTERISTICS.  SEE  SVAKA. 

C  DATA(ND*TA)-ARRAY  TO  HOLD  MESSAGE 

C  NLEN-HESSA6E  LENGTH.  ELEMENTS  t  TO  NLEN  OF  -'DATA'  HOLD  THE 
C  MESSAGE.  IF  NLEN.LT.O,  THEN  THE  MESSAGE  IS  TOO  LONG 

C  TO  FIT  IN  'DATA'.  -NLEN  IS  THE  TOTAL  MESSAGE  LENGTH  AND 

C  THE  FIRST  NDATA  ELEMENTS  ARE  RETURNED  IN  'DATA'. 


SUBROUTINE  SNDMSAt IDIST,MSID, DATA, NDATA, CHARS, MSGNO) 

C— MODULE:  MOPADS  DAVA  BASE  APPLICATION  PROGRAH5 
Cs_  C— REFERENCE:  MOPADS  VOLUME  5.18 

C— PURPOSE: 

C 

C  SNDNSA  UILL  SEND  A  MESSAGE  TO  ONE  OR  MORE  OPERATORS 
C— INPUT  PARAMETERS: 

C  IDIST-DISTRIBUTION  CODE(SEE  MSIP) 

C  O-SEND  MESSAGE  TO  OPERATOR  TYPE  MSIDC2)  IN  ALL  ftDSM'S 

C  1 -SEND  ONLY  TO  SYSTEM  AND  OPERATOR  SPECIFIED  IN  MSID(1) 

C  AND  (2) 

C  2-SEND  TO  ALL  NEXT  LEVEL  DESCENDENTS  (TO  OPERATOR  TYPE 

C  MSIDC2) ) 

C  3-SEND  TO  ALL  DESCENDENTS (OPERATOR  TYPE  MSID<2>) 

C  4— SEND  TO  ADSH  HSID(I)  AND  ALL  OF  IT5  DESCENDENTS 

C  (OPERATOR  TYPE  HSID<2)> 
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MSI8(5)-THE  MESSAGE  ID.  THE  SENDER  MUST  LOAD  THIS  ARRAY. 

MSID( 1 )-C0PY  ROU  NUMBER  OF  RECEIVER  <F0R  IDIST-T  AND  4) 

( 2) -0PERAT0R  TYPE  OF  RECEIVER  (FOR  ALL  IDIST  VALUES) 

(3) -FUNCTI0N  TYPE  ( 1 -COMMAND, 2-REQUEST  FUR  INFO, 

3-REPORT  OF  STATUS, 4-ACKNOULEDGNENT, 5- 
COMPUTER  GENERATED) 

(4) -HESSAGE  SUBTYPE (APPLICATION  DEPENDENT) 

(5) -MESSAGE  PRIORITY 

SNDMSA  DOES  NOT  CHANGE  THE  VALUES  OF  M3ID. 

DATA(NDATA) -CONTENTS  OF  THE  MESSAGE 

(NCATA  MAY  BE  ZERO  FOR  A  NULL  MESSAGE.) 

-INPUT/OUTPUT  PARAMETERS: 

CHARS(10)-MESSAGE  CHARACTERISTICS 

CHARS  (ALL  INPUT  BY  THE  USER  UNLESS  NOTED  OTHERUI^E) 


*1  1 -VOICE,  2-fljTpL 

2  ACKNOWLEDGMENT  REQUIRED,  1-YES,  2-NO 

3  UNUSED 

4  ATDL  MESSAGE  CODE  (CURRENTLY  UNUSED) 

5  TIME  MESSAGE  UAS  SENT  (OUTPUT) 

6  MESSAGE  NUMBER  (OUTPUT) 

7  SENDER  COPY  ROU  NUMBER 

8  SENDER  OPERATOR  TYPE 

9  UNUSED 
10  UNUSED 

SNDMSA  DOES  NOT  CHECK  THE  INPUT  VALUES  OF  CHARS. 
-OUTPUT  PARAMETERS: 

HSGNO-MESSAGE  NUMBER.  SAME  A»  CHARS<6) 


SUBROUTINE  SVAKA(MSID, DATA, NDATA, CHARS) 

-MODULE:  MOPADS  DATA  BASE  APPLICATION  PROGRAMS 

-REFERENCE:  MOPADS  VOLUME  5.18  1 

-PURPOSE: 

SVAKA  UILL  SAVE  A  MESSAGE  IN  THE  ACKNOULEDGHENT-MESSAGES 
DIRECTORY  OF  A  UORKING  ADSM.  SVAKA  ASSUMES  THAT  TNOU  IS 
THE  RECEIVE-TIME  FOR  THE  MESSAGE  AND  STORES  IT  IN  CHARS(3). 
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— 'INPUT  PARAMETERS! 

MSI D( 5)— THE  MESSAGE  ID 

(1>-CQPY  ROU  NUMBER  OF  THE  ADSM  THAT  IS  SAV1N6  THE 
MESSAGE. 

(2) -0PERAT0R  TYPE  OF  RECEIVER 

(3) -FUNCTI0N  TYPE( 1 -COMMAND ,2-REQUEST  FOR  INFO, 

3-REPORT  OF  STATUS, 4-ACKN0ULEDC1ENT, 5-COMPUTER 
GENERATED) 

(4) -MESSAGE  SUBTYPE 

(5) -HESSAGE  PRIORITY 

DATA (NDATA) -CONTENTS  OF  MESSAGE.  NDATA  MAY  BE  ZERO  FOR  A 
NULL  MESSAGE. 

-INPUT/OUTPUT  PARAMETERS! 

CHARS(10)-NESSAGE  CHARACTERISES 

CHARS  (ALL  INPUT  BY  THE  USER  UNLESS  NOTED  OTHERUISE) 


1 

2 

3 

4 

5 

6 

7 

8 
9 

10 


1-VOICE,  2-ATBL 

ACKNOWLEDGMENT  REQUIRED,  1-YES,  2-NO 

TIME  MESSAGE  UAS  RECE I VED < OUTPUT ) 

ATDL  MESSAGE  CODE  (CURRENTLY  UNUSED) 

TIME  MESSAGE  UAS  SENT 

MESSAGE  NUMBER 

SENDER  COPY  ROU  NUMBER 

SENDER  OPERATOR  TYPE 

UNUSED 

UNUSEO 


FUNCTION  TIMEAO 

C— MODULE!  MOPADS  DATA  BASE  APPLICATION  PROGRAMS 
C — REFERENCE:  MOPADS  VOLUME  5.18 
C— PURPOSE! 

C  TIMEA  UILL  RETURN  THE  PRESENT  SIMULATED  CLOCK  TIME  IN 
C  MILITARY  UNITS.  E.G.  IF  THE  TIME  IS  4:10  P.M.,  TIMEA*1610. 

C  0000. LE. TIMEA. LE. 2359.  TIMEA  IS  ACCURATE  TO  ONLY  THE 

C  NEAREST  MINUTE. 
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SUBROUTINE  TRAVA(NDB,IQPT,ICSQ,IDB12f ID12,IRSLT> 

--NODULE:  N0PAD3  DATA  BASE  APPLICATION  PROGRAMS 

— REFERENCE:  HOPADS  VOLUME  5. IB 

--PURPOSE: 

TRAVA  UILL  TRAVERSE  A  COMMAND  AND  CONTROL  TREE  AND  RETURN 
THE  DRAA/S  OF  ALL  CODE  12  DR'S.  IT  IS  CALLED  REPEATEDLY 
RETURNING  A  NEU  CODE  12  DRAA  EACH  TIME  UNTIL  IT  RETURNS  AN 
INDICATION  THAT  THE  TREE  IS  EXHAUSTED.  THE  ORDER  IN  UHICH  TRAVA 
RETURNS  CODE  12  DR'S  IS  NOT  PREDICTABLE. 

—  INPUT  PARAMETERS: 

NDB-DATA  BASE  ( 1 -WORKING, 2-REFERENCE) 

IOPT-OPTION 

1- 1NITIALIZE  TRAVA  FOR  A  NEU  SEARCH  OF  THE  TREE.  TRAVA 
DOES  RETURN  A  CODE  12  DRAA  FROM  THIS  CALL  IF  ONE  EXISTS 
(SEE  IRSLT) 

2- LOCATE  ANOTHER  CODE  12  DR.  A  CALL  UITH  IOPT*1  MUST 

BE  HADE  BEFORE  CALLING  UITH  I0PT=2.  THEN  EACH  SUBSEQUENT 
CALL  SHOULD  HAVE  I0PT=2. 

3- DEACTIVATE  TRAVA.  A  CALL  UITH  IOPT=3  IS  NOT  NECESSARY 
IF  IRSLT *2  ON  A  PREVIOUS  CALL. 

—INPUT/OUTPUT  PARAMETERS: 

ICSQH1-DRAA  OF  THE  COMMAND  AND  CONTROL  (CODE  7)  DR  AT  THE 
ROOT  OF  THE  TREE.  TRAVA  DOES  NOT  CHECK  THAT  ICSQ 
IS  ACTUALLY  A  CODE  7  DR. 

-OUTPUT  PARAMETERS: 

IDB12(4)-DRAA  OF  ANOTHER  CODE  12  DR  IF  1RSLT«1.  ZERO  OTHERUISE. 
ID12M1-II)  OF  THE  CODE  12  DR  IN  IDB12.  ZERO  IF  IRSLT=2. 
IRSLT-RESULT 

1 -ANOTHER  CODE  12  DR  HAS  BEEN  FOUND.  ITS  DRAA  AND  ID  ARE 
IN  IDB12  AND  ID12,  RESPECTIVELY. 

Z-THE  CODE  12  TREE  IS  EXHAUSTED.  IDB12  AND  ID12  ARE  ZERO. 
-LOCAL  VARIABLES: 

IDDL(2)-DBAA  OF  A  DUMMY  DL  CREATED  TO  STORE  CODE  12  DRAA'S 

AND  ID'S  AS  TRAVA  TRAVERSES  THE  BRANCHES  OF  THE  TREE. 


VI.  USER  INSTRUCTIONS 


1- 0  SETTING  DBAP  OPTIONS 

SUBROUTINE  APOPTA  is  used  to  net  internal  options  for  the 
DBAP.  At  present,  there  is  only  one  such  option,  the  unit  number 
of  the  MOPADS  output  file.  MOPADS  sets  this  to  the  line  printer 
output  file.  DBAP  will  write  error  messages  to  this  file. 

j 

2- 0  RETRIEVING  AIR  SCENARIO  DATA 

j 

SUBROUTINE  ASROWA  will  retrieve  the  data  for  an  aircraft 
initiation  point  or  checkpoint  from  the  data  base.  ASROWA  is 
called  only  from  the  control  system  module. 

3- 0  MISCELLANEOUS  DATA  BASE  OPERATORS 

fr  i 

'The  DBAP  has  several  programs  that  perform  needed  data  base 
operations.  These  programs  are  explained  below: 


CCDLA  -  maintains  the  "Copy  Counter” 

data  list  for  a  simulation  data 
set  (pee  Polito  (1983b). 

CFDLA  -  copies  data  lists  from  one 

directory  to  another 

CPDRA  -  copies  directories  from  one  place 

#  in  a  directory  to  another 

CREATA  -  creates  an  empty  MOPADS  data  base 

INIDLA  -  copies  information  within  s 

I  single  data  list 

NCOPYA,  NFST1A,  -  performs  initialization  of  the 

NFST2A ,  NFST3A  MSAINT  data  structure  from  the 

data  base  file 

TRAVA  -  finds  all  air  defense  units  in  a 

simulation  data  set 


4-0  OPERATOR  AND  ENVIRONMENTAL  STATE  VECTORS  AND  TASK  DATA 


Several  programs  are  available  for  accessing  information  in 
the  operator  state  vectors,  the  environmental  state  vectors,  and 
the  task  specific  data.  The  programs  are: 


GETEVA 

retrieve  information  from  an 
environmental  state  vector 

GETOVA 

- 

retrieve  information  from  an 
operator  state  vector 

GETTSA 

- 

retrieve  information  from  the 
task  data 

GTSEA 

- 

retrieve  a  single  element  of  an 
environmental  state  vector 

FTSPA 

- 

change  a  single  element  of  an 
environmental  state  vector 

PUTEVA 

- 

change  information  in  an  environ¬ 
mental  state  vector 

P17T0VA 

- 

change  information  in  an  operator 
state  vector 

PUTTSA 

- 

change  information  in  the  task 
data 

5-0.  MESSAGES 

There  are  two  types  of  messages,  l)  original  messages  and 
2)  acknowledgement  messages.  The  DBAP  provides  facilities  to 
manage  both  types.  The  following  programs  are  provided  for 
original  messages  and  acknowledgement  messages. 


FNDMSA 

locate  an  outstanding  message 
that  satifies  specified  criteria 

RECMSA 

- 

receive  a  message 

SNDMSA 

- 

send  a  message 
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FNDAKA 


locate  an  acknowledgement  message 
that  satisfies  specified 
conditions 


REPAKA 

retrieve  an  acknowledgement 
message 

SVAKA 

“ 

save  a  message  that  requires 
acknowledgment 

Acknowledgement  messages  are  simply  copies  of  original  messages  that 
require  an  acknowledgement.  The  operator  saves  these  in  his 
ACKNOWLEDGEMENT-MESSAGES  directory  for  later  reference.  FNDAKA, 
RETAKA,  and  SVAKA  operate  on  this  directory. 

6-0  TRACK  DATA 

Each  air  defense  unit  maintains  information  on  tracks  in  its 
**Track  Data"  data  list.  The  DBAP  provides  programs  to  manage  this 
information. 

FTKAA 

- 

finds  an  unused  row  in  the  "track 
data"  data  list 

GTKAA 

- 

locate  a  track  that  satisfies 
specifiied  conditions 

GTKBA 

- 

retrive  one  row  of  track  data 

GTKCA 

- 

retrieve  one  element  of  a  row 
of  track  data 

FTKBA 

- 

change  the  contents  of  one  row 
of  track  data 

PTKCA 


change  one  element  of  a  row  of 
track  data 


7-0  STACK  OPERATIONS 


The  DBAP  has  programs  to  manipulate  the  operators'  task  stack 


CLRSTA 

-  empty  one  operator's  task 

stack 

P0PSTA 

-  retrieve  the  last  element 
•che  stack 

from 

PSHSTA 

-  add  an  element  to  the  end  of  the 
stack 

8-0  Goals 

The  DBAP  has  two  programs  dealing  with  operator  goals: 


CHKGLA 

EVLPA 

9-0  MISCELLANEOUS  FUNCTIONS 
NECCA 

CENCA 

TIMEA 


check  to  see  if  a  particular 
aerator  has  a  specified  goal 

evaluate  a  goal  priority  function 
for  a  specified  operator 


implements  the  fucntion  NECC 
{Number  Equivalent  of  a 
Character  Code)  that  converts 
character  strings  to  integers 

performs  the  inverse  NECC  func¬ 
tion.  Converts  an  integer  to  a 
character  string. 

returns  the  current  time  in 
military  format  (e.g.,  1620) 


10-0  ERROR  PROCESSING 

The  error  processing  program  in  the  DBAP  is  discussed  in 
Section  VII. 


VII.  ERROR  PROCESSING 


SUBROUTINE  ERROR A  processes  run  time  errors  for  the  DBAP  and, 
in  fact,  is  called  by  programs  outside  the  BBAP,  too.  The  parameters 
of  ERRORA  include  a  text  message  of  arbitrary  length,  the  calling 
subprogram  name,  and  lists  of  integer  and  real  parameters  to  print. 
Also,  if  a  data  base  error  occurred,  the  data  base  address  of  the 
offending  directory  or  data  list  can  be  passed  to  ERRORA.  ERRORA 
will  attempt  to  print  the  contents  of  this  data  base  entry. 

ERRORA  always  terminates  execution  by  performing  a  deliberate 
FORTRAN  error.  It  does  this  so  that  Traceback  information  will  be 
obtained  (if  it  is  available)  to  aid  in  debugging. 


Z-37 


VIII. 


COMMON  VARIABLE  DEFINITIONS 


There  is  only  one  labeled  COMMON  area  in  the  DBAP.  It  is 
labeled  COM1A.,  and  it  has  only  one  variable. 


Variable  Name  Default  Name  Definition 


JOUTA 


unit  number  of  the 
file  to  write  error 
information  to 
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